Firefox issue: can't login as FF remains in 'different origin' state for subsequent XHR requests

[stefano-xy]

Describe the bug

I put the right username and password in the login window, no error message appears but I'm pushed back again to the same login window.

To Reproduce

See steps above. It's random. I think it's related to #884 because it's in the same IPv4/IPv6 mixed setup, and I've never seen such behavior before the fix. So I assume it may be related to the problem, not fully solved by the fix. It happens with the same frequency the other bug happened.

openmediavault Server (please complete the following information):

• OS version: Linux
• openmediavault version: 5.5.21

Client (please complete the following information):

• Device: Windows
• OS: 10
• Browser: Firefox
• Version: 80.0.1

Additional context

Looking at the Firefox network log, this is what I see.

Hostname is http://omv5/.

Initial request:

GET / HTTP/1.1
Host: omv5
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:80.0) Gecko/20100101 Firefox/80.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Pragma: no-cache
Cache-Control: no-cache
--
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 08 Jan 2021 16:45:09 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: X-OPENMEDIAVAULT-SESSIONID=734sd20jvok9e4tj05qgg5s147; path=/; HttpOnly; SameSite=Strict
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self' data:;
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Content-Encoding: gzip

After filling the authentication window:

POST /rpc.php HTTP/1.1
Host: omv5
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:80.0) Gecko/20100101 Firefox/80.0
Accept: */*
Accept-Encoding: gzip, deflate
Content-Type: application/json
X-Requested-With: XMLHttpRequest
Content-Length: 109
Origin: http://omv5
DNT: 1
Connection: keep-alive
Referer: http://omv5/
Cookie: X-OPENMEDIAVAULT-LOGIN-***=The+beginning+of+knowledge+is+the+discovery+of+something+we+do+not+understand.; X-OPENMEDIAVAULT-LOGIN-***=I+must+not+fear.+Fear+is+the+mind-killer.+Fear+is+the+little-death+that+brings+total+obliteration.+I+will+face+my+fear.+I+will+permit+it+to+pass+over+me+and+through+me.+And+when+it+has+gone+past+I+will+turn+the+inner+eye+to+see+its+path.+Where+the+fear+has+gone+there+will+be+nothing.+Only+I+will+remain.; X-OPENMEDIAVAULT-LOGIN-***=Without+change+something+sleeps+inside+us%2C+and+seldom+awakens.+The+sleeper+must+awaken.; X-OPENMEDIAVAULT-SESSIONID=734sd20jvok9e4tj05qgg5s147; X-OPENMEDIAVAULT-LOGIN-***=What+does+a+mirror+look+at%3F
--
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 08 Jan 2021 16:47:38 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: X-OPENMEDIAVAULT-SESSIONID=h3mg3r129vhvd1fd8li7qitj5k; path=/; HttpOnly; SameSite=Strict
Cache-Control: max-age=0, no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0
Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self' data:;
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block

Then the browser reloads /:

GET / HTTP/1.1
Host: omv5
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:80.0) Gecko/20100101 Firefox/80.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Pragma: no-cache
Cache-Control: no-cache
--
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 08 Jan 2021 16:47:39 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: X-OPENMEDIAVAULT-SESSIONID=iu5g6kcuf5d8kvjtidiq8acijn; path=/; HttpOnly; SameSite=Strict
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self' data:;
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Content-Encoding: gzip

The continous change of SESSIONID cookie is suspicious. It's also not clear to me when not all the cookies are re-sent at every request, although that's maybe due to the fact that the second call is XMLHttpRequest, so there's the JS behavior also in the game I can't observe.

[mi-hol]

You are using a quite old version of Firefox. Could you please verify with 84.0.2?

[votdev]

Have you tested Chrome? A user reported the same issue with Firefox, but was able to login using Chrome.

https://forum.openmediavault.org/index.php?thread/37442-firefox-login-loop/

[stefano-xy]

I'll try with other browsers, FF 80 was released Aug 2020, it's January 2021 and "quite old" looks like an exaggeration to me. Nevertheless, it can't be a generalized browser problem, half of the internet would be affected. I'll try to debug with other browsers, but the solution can't be "upgrade to Firefox 84 or switch to Chrome". It should work with modern browsers, any decent version.

[stefano-xy]

Can you briefly explain how the login process is supposed to work? It's not a simple POST, it's done via XMLHttpRequest, login information is passed as cookie with Dune quotes ... just to understand, thanks.

[votdev]

The issue looks like the same like https://github.com/openmediavault/openmediavault/issues/864. The user reported that the desktop Firefox works, but Android browser fails.

[votdev]

Here are the relevant parts:

• https://github.com/openmediavault/openmediavault/blob/master/deb/openmediavault/var/www/openmediavault/rpc/session.inc#L48
• https://github.com/openmediavault/openmediavault/blob/master/deb/openmediavault/usr/share/openmediavault/engined/rpc/usermgmt.inc#L72
• https://github.com/openmediavault/openmediavault/blob/master/deb/openmediavault/var/www/openmediavault/js/omv/window/Login.js#L143
• https://github.com/openmediavault/openmediavault/blob/master/deb/openmediavault/var/www/openmediavault/index.php#L37

The UI executes a RPC to authenticate the user. After that index.html decides whether to render the workbench or login page. And this is surely the reason for your issue. But i don't understand why the session information should get lost. I never was able to reproduce this behaviour.

[stefano-xy]

Let's start to fix the cookies with Dune quotes: I understand they're used just to avoid re-sending emails, but I get often emails, I have 5 of those cookies, and I'm using always the same account, that is guess what admin by the way. That's probably due to a bug here:

https://github.com/openmediavault/openmediavault/blob/0f57140536b8f72e93da375fd8e1150393e1a45b/deb/openmediavault/var/www/openmediavault/rpc/session.inc#L104

crypt(username, hashedUsername) is used generate the username hash, that is compared with a hash generated instead using password_hash(username, PASSWORD_DEFAULT). Different salts probably, potentially different algorithms. It also looks like password_hash is not deterministic and to verify if a password (username in this case) matches, you should use the corresponding password_verify function. Alternatively, use crypt everywhere with a fixed salt.

Search for the login loop continues.

[votdev]

crypt(username, hashedUsername) is used generate the username hash, that is compared with a hash generated instead using password_hash(username, PASSWORD_DEFAULT). Different salts probably, potentially different algorithms. It also looks like password_hash is not deterministic and to verify if a password (username in this case) matches, you should use the corresponding password_verify function. Alternatively, use crypt everywhere with a fixed salt.

Uhhhh, good spotting. I think i will stay using the hash functions.

Update: The PHP documentation says.

password_hash() creates a new password hash using a strong one-way hashing algorithm. password_hash() is compatible with crypt(). Therefore, password hashes created by crypt() can be used with password_hash(). 

[votdev]

Using

$hashedUsername = urldecode($matches[1]);
if (password_verify($params['username'], $hashedUsername)) {
    $firstLogIn = FALSE;
    break;
}

looks better to me. I think password_verify was not available at the time the code was implemented.

[mi-hol]

I'll try with other browsers, FF 80 was released Aug 2020, it's January 2021 and "quite old" looks like an exaggeration to me. Nevertheless, it can't be a generalized browser problem, half of the internet would be affected.

Appreciate your support! Guess we are both guilty of exaggerating :) Chromium engine based browser account for over 80% of web access by now. Mozilla is kind of "the last man standing" to fight the dominance, but given their financial issue I wouldn't bet money on them.

[stefano-xy]

It's not the Firefox version the problem, as confirmed by the jac2598 on the forum. I can't replicate it today, when it happens, it happens frequently, but sometimes it doesn't happen for days. In this situation testing with another browser can only return false negatives.

According to my trace, it seems the browser loses the cookies when requesting / after logging on. I could not reproduce this behavior, it could be in JS.

[stefano-xy]

I can replicate again, after many days, with 5.5.21. I'm trying to debug the JS, since it seems the session cookie is lost between the login RPC and the next call to GET /. I'm trying to understand where to look to understand what happens after fireEvent, that does happen with valid login response.

After here: https://github.com/openmediavault/openmediavault/blob/7f4de6a65e2b719c831b0bdb19f838241272e0c6/deb/openmediavault/var/www/openmediavault/js/omv/window/Login.js#L151

Where does the flow go? Sorry I'm not a JS expert, it's the first time I'm trying to debug in the browser.

That's the response:

authenticated: true
permissions: {
role: "admin"
}
​<prototype>: {…}
username: "admin"

What next?

[stefano-xy]

The cookie returned by the RPC call is lost when the page is reloaded by:

listeners: {
  login: function(wnd, response) {
    // Close the window now.
    wnd.close();
    // Display loading progress dialog. This will
    // be displayed until the web administration
    // interface is loaded and rendered.
    Ext.getBody().mask(
    _("Loading, please wait ..."));
    // Reload page to render the web
    // administration interface.
    document.location.reload(true);
  }
}

Until the last line is reached, OVM cookies are where they should be. These could be related or provide inspiration to further track the issue:

https://stackoverflow.com/questions/32040090/lose-cookie-session-when-reload-page https://github.com/github/fetch/issues/386

Note that also the cookie with the Dune quote is lost, not just the session cookie.

[stefano-xy]

I can reproduce it and control it !! The PHP session cookie has samesite: strict, and this sometimes prevents the cookie to be sent back. When instead I configure PHP use use samesite: lax, the problem is solved. It's 100% linked to this setting because I can switch back and forth and the problem appear and disappear in the same browser tab.

I think we're hitting some kind of undefined behavior of the browser, probably related to the fact that my base URL is http://omv5. What's the site of it? I asked on StackOverflow (https://stackoverflow.com/questions/65743568/how-does-samesite-strict-work-when-only-the-hostname-is-present).

If the browser believes that the GET / request is not on the same site, it blocks the cookies. Specifying lax relax this check and login works. Putting back strict enforces the checks again.

I think we should review the CORS settings of the OMV control panel and investigate the potential use of .withCredentials parameter of XHR requests and related headers (https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/withCredentials), because it's a tricky topic.

[votdev]

I can reproduce it and control it !! The PHP session cookie has samesite: strict, and this sometimes prevents the cookie to be sent back. When instead I configure PHP use use samesite: lax, the problem is solved. It's 100% linked to this setting because I can switch back and forth and the problem appear and disappear in the same browser tab.

Using strict is by intention, lowering the security is not the way to go to fix a bug or strange behavior in the browser.

I think we should review the CORS settings of the OMV control panel and investigate the potential use of .withCredentials parameter of XHR requests and related headers (developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/withCredentials), because it's a tricky topic.

You can give this a try by adding withCredentials: true, to the file /var/www/openmediavault/js/omv/Rpc.js below line 32. See also https://docs.sencha.com/extjs/6.2.0/classic/Ext.data.Connection.html#cfg-withCredentials.

[stefano-xy]

I'm not saying to blindly relax that parameter, I'm just reporting that the problem is linked to this setting. My explanation is that the browser doesn't (always?) consider the URL as "same site". We should understand why and make sure it does. It might be related to hostnames without domains, not an uncommon setup at home. That's why I'm asking for which precise hostnames are used in the forum. Mine is http://omv5. I can't reproduce it with http://omv5.fritz.box, but as said it could be a false negative.

I tried with withCredentials: true and it doesn't fix it. CORS is a tricky topic, there are headers to set and return, I'm not an expert of it. The problem is not the XHR request that doesn't contain the cookies, what as far as I understood withCredentials: true could solve, but the subsequent GET / for which JS has no control. Note however that withCredentials: true would relax the check similarly to samesite: lax.

I think we should doublecheck / rethink / review and (in case) redesign which headers are returned by OMV backend for /* and in particular for /rpc.php. CORS has changed during the years, new headers are introduced, ...

For the discussion about SameSite, please see https://web.dev/samesite-cookies-explained/#explicitly-state-cookie-usage-with-the-samesite-attribute. Lax doesn't automatically mean insecure, but I agree it should not be needed and I do think the root cause is somewhere else.

[stefano-xy]

A visual representation of what's happening. RPC logs in, it receives the new session cookie. This is not sent back to the subsequent GET /, that resets the session sending back a new session cookie (preventing login). That session cookie instead is used for all the subsequent requests.

The second cookie of the left column is the one with quote of Dune.

[stefano-xy]

I now typed http://omv5/ in the browser, pressed enter, something must have reset because now it works without any problem. I can't reproduce it anymore. Given the frequency, it will reappear during next week. Have a nice weekend everybody 😄 .

[votdev]

I now typed http://omv5/ in the browser, pressed enter, something must have reset because now it works without any problem. I can't reproduce it anymore. Given the frequency, it will reappear during next week. Have a nice weekend everybody smile .

That sounds really really strange :-).

[georgekav2]

@ragazzojp Do you use any dashboard like heimdall to access omv site? I was able to replicate/isolate as following:

1. Open your dashboard
2. Click on the omv button Latest Firefox and OMV versions.

On all requests, I see that cookies are NOT send. Even If I refresh (F5) still the cookie is not sent. On the contrary, if I click into url bar and then , the browser is forwarding the cookies properly and on next login I am into OMV.

In the beginning I thought that it is the referrer header, but it is not. I disable it with no result. Should be intended behavior for strict mode, according to Mozilla: "Cookies will only be sent in a first-party context and not be sent along with requests initiated by third party websites." https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite

Also relevant: https://stackoverflow.com/questions/41841880/what-is-the-benefit-of-blocking-cookie-for-clicked-link-samesite-strict

In conclusion, it looks like desired behavior for strict mode not to forward cookies on clicked urls even if the domain of the stored cookie is the same as the url hostname.

PS. After searching around there is also this bug/issue and that concerns also same domain redirects. There is a comment there with a test site that redirects to samesite domain and still the strict policy in Firefox do not forward the cookie: https://bugzilla.mozilla.org/show_bug.cgi?id=1465402

[stefano-xy]

I'm not using any dashboard, I'm just typing the URL in the browser. The bug you mentioned is closed as duplicate of another one, but this other one is the opposite (cookie sent when not supposed to). I'll reopen it and link it to this discussion, I have no other explanation than a bug in FF.

[georgekav2]

What happens on private browsing window in FF? I am able to replicate there as well. When we land on omv hostname (mine is omv.home) via a link from an other hostname, the firefox do not send initially the cookie (correct), however, on any following redirect on same domain it continues to restrict cookie sending in the request. Chrome is restricting on the first, but then starts sending on any following request.

[stefano-xy]

I don't know I can't replicate it. It happens a couple of times a week in my setup. Sometimes it happens in a tab and does not happen in another tab of the same browser instance. Given the frequency of false negatives, I can't tell you. Comment please on the FF bug stating your FF version, or post it here. I'll post details there and a link to this github issue, because I'm starting to believe if's a FF bug.

If you can reproduce the bug, type explicitely http://omv.home and press enter in the URL bar, then try again.

[georgekav2]

If I type the url myself works always.

Is it possible to try a dummy html file with a link to omv such as the following

<!DOCTYPE html>
<html>
<body>
<a href="http://yourhostname">OMV link</a>
</body>
</html>

After clicking on such link does any future refresh of FF start sending cooking or remains prohibited? I am looking to isolate in case we are looking at the same issue, or potential different bug sources with same outcome.

[stefano-xy]

I can replicate it and reproduce it !! I know when it happens and how to reliably reproduce it. You're right, it's due to the fact that you reach the OMV login page coming from website, similar to the case you wanted me to test. In my case, like the dashboard you suggested, I opened the OMV page from the control page of ESXi, that is another host on the same network of OMV. In ESXi, there's a link like:

<a href="http://omv5" target="_blank">omv5</a>

Clicking on it, I reach the login page that doesn't work. I'll now investigate further. It could be a FF issue as an OMV issue.

I can replicate and reproduce it with FF 80, both standard and private mode. Cannot replicate with the Chromium-based MS Edge.

[stefano-xy]

I can replicate it and it seems to be independent of OMV. Somehow the GET / and POST /rpc.php are handled as independent sites from FF. It's probably not an OMV bug, unless this is the expected behavior from FF. I'm posting here two files to replicate and test it, I'll ask FF team or someone with specific know-how to address it.

test.zip

In the zip file you'll find two files. serve.py and test.html. Run python serve.py, it starts a simple HTTP server on localhost:8080. Start Firefox private mode and type manually that address in the URL and press enter. GET / simply prints the request back. The are two buttons in the page: Send XHR and Refresh. Press Refresh multiple times, you'll notice that nothing happens, requests are all similar (implemented via document.location.reload(true). Press Send XHR, it silently sends POST / as XHR. The response sets a cookie with SameSite: Strict. Pressing Refresh again, you should see the cookie reflected back.

Close Firefox private mode and reopen it.

Open link.html by dragging the file on the browser. There's a link to http://localhost:8080, click on it with the HTTP server still running. Perform the experiment above, clicking Refresh multiple times, clicking Send XHR, clicking Refresh again. That's basically what OMV does with the login window. In my setup I don't see the cookie reflected back anymore.

Last but not least, setting r.withCredentials = true before sending the XHR doesn't help.

[georgekav2]

I dont think you need such complex replication vector, as it is more general than the specific process of omv you try to replicate. Even a simple site like https://cookie-lab-app.vercel.app/ is accessed via a link on a different domain will lead to the bug. And of course even simpler, just F5 after landing to the page via a crossdomain link.

I believe the issue in on FF unless they implement a part of the samesite strict web standard that we are not well aware and that this is actually not allowed.

But in summary, FF remains in 'different origin' state after first being flagged as such, regardless of manually refreshed or using js. chromium skips send the cookie the first time you land on the page, but any manual or automated refresh/redirect is then treated as same origin.

[stefano-xy]

Yes, "FF remains in 'different origin' state for subsequent XHR requests" elegantly summarizes the issue. It may affect other setups than XHR although. I'll notify FF team and see their answer: this could be on purpose, by mistake, or according to the specs and Chrome is doing it wrong.

[georgekav2]

Are you sure about the XHR? For me its the GET right after the post to rpc that is missing the X-OPENMEDIAVAULT-SESSIONID for example. All other requests seems to carry the cookie.

Btw, something else, if you login successfully, and you then click again via a link to replicate the bug, you session is disconnected. And this behavior is also for Chrome.

[stefano-xy]

Look at the network traffic I posted above. The XHR has some cookie (older ones probably), and it receives a new cookie (to bind to the session where the user is authenticated), that is even stored in FF. The subsequent GET / triggered by document.location.reload(true) doesn't send it back. I have the feeling the XHR is setting the cookie somewhere else.

[georgekav2]

Neither any manual refresh on /. A typed url (non-linked) on / return the previous session cookie. If it was on the rpc post then why reentering the site via a link loses the session?

[mi-hol]

@ragazzojp, would you please change the issue title to something like "Firefox issue: Can't login to OMV, due to FF remains in 'different origin' state for subsequent XHR requests" ?

[georgekav2]

I can confirm the issue in FF on Android. @ragazzojp how did you try the Lax on omv? I changed the setcookie in https://github.com/openmediavault/openmediavault/blob/master/deb/openmediavault/var/www/openmediavault/rpc/session.inc#L139 however even after restart it is not taken into account; php still returns strict cookie.

[stefano-xy]

There's a setting in /etc/php/7.3/fpm, restart then the service with service php7.3-fpm restart. Session cookie is managed by PHP, OMV doesn't do much about it, cookie is even HttpOnly, the JS can't see and touch it.

Lax works, because lax allows sending cookies when navigating to the site. For example this could enable sending the cookie on the first GET /, instead of forcing the users to login every time. (TBC)

[votdev]

I can confirm the issue in FF on Android. @ragazzojp how did you try the Lax on omv? I changed the setcookie in https://github.com/openmediavault/openmediavault/blob/master/deb/openmediavault/var/www/openmediavault/rpc/session.inc#L139 however even after restart it is not taken into account; php still returns strict cookie.

You need to restart the daemon process using monit restart omv-engined.

[stefano-xy]

@georgekav2 , the cookie you can change in OMV source code is the one with the quote of Dune, that is used to prevent sending an email at every login. The session cookie is controlled by the setting I pointed you to, in /etc/php/7.3/fpm/php.ini.

[georgekav2]

@ragazzojp I change the samesite setting to Lac in /etc/php/7.3/fpm/php.ini and also restarted the php7.3-fpm but still it sends strict cookie. I think I miss something on how omv configures the cookies.

For the ones need to follow the situation, in this bug report you will see that there is work in progress toward the right direction. In short F5 user refresh is considered dangerous to send strict cookies for Firefox devs, but they seem to be willing to align with Chrome on .reload() https://bugzilla.mozilla.org/show_bug.cgi?id=1459321

And a nice site for testing: https://samesitetest.com/cookies/set

@votdev given the inconsistent behavior yet on strict cookie, what can we do on omv site to mitigate? If we keep the session cookie as strict, is it potentially feasible to re-login/authorize user the next time he offers his previous stored session cookie (for example after accessing/refreshing the site properly). At the moment he gets automatically disconnected in all browsers tests and need to login on new session cookie site offers.

[votdev]

@ragazzojp I change the samesite setting to Lac in /etc/php/7.3/fpm/php.ini and also restarted the php7.3-fpm but still it sends strict cookie. I think I miss something on how omv configures the cookies.

You'll find the php.ini used by OMV here, and the PHPFPM configuration is created here.

For the ones need to follow the situation, in this bug report you will see that there is work in progress toward the right direction. In short F5 user refresh is considered dangerous to send strict cookies for Firefox devs, but they seem to be willing to align with Chrome on .reload() bugzilla.mozilla.org/show_bug.cgi?id=1459321

And a nice site for testing: samesitetest.com/cookies/set

@votdev given the inconsistent behavior yet on strict cookie, what can we do on omv site to mitigate? If we keep the session cookie as strict, is it potentially feasible to re-login/authorize user the next time he offers his previous stored session cookie (for example after accessing/refreshing the site properly). At the moment he gets automatically disconnected in all browsers tests and need to login on new session cookie site offers.

Lowering the strict mode (resulting in less security) to workaround a bug in a browser should not be the solution to go. The only thing that come to my mind is to suggest those users to switch the browser till Firefox has fixed the bug.

[TheLoliCatcher]

I have a similar issue in that i can login fine if i manually enter the ip into the address bar but i can't if i use my homepage (just a page of hyperlinks) as it will just refresh the page. This worked fine with OMV4 in firefox and works as-is in chrome (with OMV5). This is in version 85.0.2 of Firefox by the way.

I've tried: clearing site data refreshing firefox running in safe mode

[georgekav2]

Unless Firefox fix that, your only solution is to modify for your installation the session cookie to be Lax

[mi-hol]

@ragazzojp does the new Firefox version 86 fix the issue?

[georgekav2]

hello @mi-hol, no the issue remain, just tested.

[merc4derp]

Still getting this problem on omv 5.6.16-1 with firefox 92. Any progress or workarounds? Everything working fine with chrome/edge btw.

[votdev]

Still getting this problem on omv 5.6.16-1 with firefox 92. Any progress or workarounds? Everything working fine with chrome/edge btw.

Please give OMV6 a try, the problem should not occur there anymore.

[merc4derp]

Still getting this problem on omv 5.6.16-1 with firefox 92. Any progress or workarounds? Everything working fine with chrome/edge btw.

Please give OMV6 a try, the problem should not occur there anymore.

Just tried it in a VM and can confirm the issue is fixed there.

Not gonna migrate before it gets properly released, but at least that's something to look forward to.

Not a fan of the new UI btw.

[LordNex]

Still happening under iOS with both safari and chrome. Going to download FF and Edge to see if that'll work

[votdev]

Still happening under iOS with both safari and chrome. Going to download FF and Edge to see if that'll work

Please use OMV6. OMV5 is EOL after 30.06.2022.

[LordNex]

What’s the best migration strategy? Full reload, will it still have the data?

On Jun 21, 2022, at 1:37 AM, Volker Theile @.***> wrote:



Still happening under iOS with both safari and chrome. Going to download FF and Edge to see if that'll work

Please use OMV6. OMV5 is EOL after 30.06.2022.

— Reply to this email directly, view it on GitHubhttps://github.com/openmediavault/openmediavault/issues/926#issuecomment-1161323678, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACGXNJFO7JCZQWXNCEWFP4DVQFPI5ANCNFSM4V2XBQKQ. You are receiving this because you commented.Message ID: @.***>

[georgekav2]

You will have to reinstall and reconfigure the omv6. Data in drives are not affected of course

[votdev]

What’s the best migration strategy? Full reload, will it still have the data? On Jun 21, 2022, at 1:37 AM, Volker Theile @.> wrote:  Still happening under iOS with both safari and chrome. Going to download FF and Edge to see if that'll work Please use OMV6. OMV5 is EOL after 30.06.2022. — Reply to this email directly, view it on GitHub<#926 (comment)>, or unsubscribe<github.com/notifications/unsubscribe-auth/ACGXNJFO7JCZQWXNCEWFP4DVQFPI5ANCNFSM4V2XBQKQ>. You are receiving this because you commented.Message ID: @.>

Simply run omv-release-upgrade. Make sure all plugins are available for OMV6, otherwise uninstall them before migration. Check the forum to get all relevant information.