I’ve been experiencing an issue lately where when I try to connect to the Duplicati GUI in Firefox or Safari, I get an error saying “The connection to the server is lost, attempting again in 0:00”. Looking at the web developer console in Firefox, there are a lot of errors saying: “Cookie “xsrf-token” has been rejected because it is already expired.” and “Missing XSRF token please reload page”. I’ve tried reloading the page, using private browsing, even using Firefox on a different computer with a clean install of Fedora, the issue persists. What is curious though is that accessing the web GUI via chromium-based browsers seems to work fine and it would appear that my backups are still functional. Any idea what might be going on or how to further diagnose this issue?
I am not a web developer (so if any are out there, feel free to jump in), but I’d suggest looking in Chrome to see whether you are in fact getting already-expired cookies, e.g. from a time zone or clock setup problem.
This method I made might help debug. Press F12 on a Duplicati page, go to Application on top menu, then expand Cookies on left menu and find the one for Duplicati URL. In data table, hover over Expires for xsrf-token to see if time there is earlier than current GMT time. Ordinarily, I think these are 10 minutes in future.
Firefox F12 under Storage → Cookies → yours has kind of a fun self-refreshing display about cookie times however it looks like at least the warning part of Firefox cookie rejection is done for a recent enhancement. A claimed regression leads to Console warnings “Cookie has been rejected because it is already expired.”, the source change, and further discussion, but first thing I’d suggest is to check all clocks and time zones.
Thanks for the help! I took a look at the cookie information in Chrome and it seems that the cookie is getting stored with the correct expiration date of 10 minutes in the future.
It looks like the cookie isn’t even getting stored in Firefox, just getting rejected outright, so I’m not sure how to check the expiration time that Firefox is getting.
I noticed a new warning in Firefox saying: Cookie “xsrf-token” will be soon rejected because it has the “SameSite” attribute set to “None” or an invalid value, without the “secure” attribute. To know more about the “SameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite
Firefox is also printing a warning stating:
XHRGEThttp://192.168.1.4:8200/api/v1/serverstate/?lasteventid=-1&longpoll=false&duration=299s
[HTTP/1.1 400 Missing XSRF Token. Please reload the page 4ms]
xsrf-token
expires "2021-02-04T23:39:51.000Z"
path "/"
value "NPifdNeejlSIWK6E7uLIxCeNd8RH4lWeqa9PsjjVxPQ="
default-theme "ngax"
The expiration time listed here seems to be the same time the error appears, not 10 minutes in the future.
By experiment, it looks like F12, pick Network from top menu, then All (further right) and Cookies under it. Look through some of the 200 responses, and eventually Response Cookies will show an xsrf-token and expires, e.g. expires: 2021-02-05T00:54:31.000Z. The display in the GUI looks a lot like that warning, except the ones I see are 10 minutes ahead. Maybe this error path doesn’t Add a cookie. Maybe sent old?
But what OS is this, and (back to prior questions) did you check timezone?
The computer clock can look completely right yet actually have the wrong UTC time, although if you sync time from somewhere else, this seems unlikely. If you do manual time set with wrong timezone, it’s likely.
Other random questions are whether you have the browser going to multiple Duplicati. This can interfere.
Another random question is whether you have a GUI password set. This sometimes needs a refresh to fix so that login can be done again. Regarding refresh, you might as well also try to do some hard refreshing:
Thanks again for the help! You were right, the time on the server was about 15 minutes behind reality. I turned on NTP syncing, so hopefully that won’t be an issue again. Setting the correct time and restarting the Duplicati server resolved the issue. It seems that either Chrome is more tolerant of an expired cookie than Firefox or at least the implementation of how they calculate the time differs between the two browsers.