Can't access v1.26.0 on localhost

Support
1

My computers just upgraded to v1.26.0, but I can’t access the Web GUI on two of them (through localhost:8384). Another one has updated as well, and I can still use the Web GUI (hostname:8384 on my LAN).

On the two that don’t work anymore, the page is constantly refreshing itself. I can see two HTTP 404 errors on the console, and a few console.log()s. I can’t read any details because the console is cleared on refresh… Same with the network tab, I can’t see anything there.

On one of the computers I was first shown the new login page, and then the refreshes started. On the other it didn’t send me through the login page, I was sent straight to “home” and refreshes.

1 Like
2

Please provide more details on the OS and the browser. Also, please check in multiple browsers too.

3

Firefox and Chrome both have an option like Keep Logs which preserves the network tab.

1 Like
4
5

I’m using Firefox beta (120.0b6 currently) on Debian testing. I’ll install Chromium to try too.

The network tab is completely empty. On the console it’s always this on repeat:

18:34:51.537 Navigated to http://localhost:8384/
18:34:52.426 TypeError: a.default.detectStore(...) is undefined h1-check.js:1:1301
18:34:53.324 loadFormIntoScope deviceEditor syncthingController.js:2121:21
18:34:53.337 loadFormIntoScope folderEditor syncthingController.js:2121:21
18:34:53.452 loadFormIntoScope deviceEditor syncthingController.js:2121:21
18:34:53.481 XHRGET
http://localhost:8384/rest/events?limit=1
[HTTP/1.1 403 Forbidden 0ms]

18:34:53.551 Navigated to http://localhost:8384/
18:34:54.304 TypeError: a.default.detectStore(...) is undefined h1-check.js:1:1301
18:34:54.957 loadFormIntoScope deviceEditor syncthingController.js:2121:21
18:34:54.969 loadFormIntoScope folderEditor syncthingController.js:2121:21
18:34:55.063 loadFormIntoScope deviceEditor syncthingController.js:2121:21
18:34:55.078 XHRGET
http://localhost:8384/rest/events?limit=1
[HTTP/1.1 403 Forbidden 0ms]

18:34:55.187 Navigated to http://localhost:8384/
18:34:55.902 TypeError: a.default.detectStore(...) is undefined h1-check.js:1:1301
18:34:55.925 GET
http://localhost:8384/assets/img/favicon-{{syncthingStatus()}}.png
[HTTP/1.1 404 Not Found 0ms]

18:34:56.937 loadFormIntoScope deviceEditor syncthingController.js:2121:21
18:34:56.950 loadFormIntoScope folderEditor syncthingController.js:2121:21
18:34:57.058 loadFormIntoScope deviceEditor syncthingController.js:2121:21
18:34:57.096 XHRGET
http://localhost:8384/rest/events?limit=1
[HTTP/1.1 403 Forbidden 0ms]

18:34:57.220 Navigated to http://localhost:8384/
6

Both Chromium and Falkon work correctly. Could it be some sort of clash between the localhost instance and the other instance (on a different computer of the LAN)? The username is the same.

7

Does Ctrl+F5 fix it?

8

It doesn’t, unfortunately…

9

After clearing the related cookies &c for localhost and the other LAN host, both are working again…

I wonder what happened

3 Likes
10

Adding a little data… From a Windows 10 machine running Firefox 115.4.0esr (64-bit), I am able to reach a linux (rPi4) running Syncthing v1.24.0 with the normal Syncthing web gui. The same Windows 10 machine with the same Firefox cannot reach localhost Syncthing V1.26.0 (Win 64/AMD). However, I can work around this using Microsoft Edge. The Firefox instance also fails to show the web gui for a nearby Mac Mini running Syncthing v1.26.0 MacOS 64 Arm. On that Mac Mini, the latest Firefox displays the gui just fine. Thus, it looks like we’re looking for some failing interaction between Syncthing V1.26.0 (Win 64/AMD) and recent Firefox.

11

…that is, recent Firefox only on Windows.

1 Like
12

Did you try ^ ?

13

Yes, that fixed reaching the Mac Mini. Now to figure out how to clear cookies for localhost…

14

127.0.0.1 found the cookies, all better! Thanks for the pointers.

1 Like
15

As a fan and advocate for Syncthing, I’m glad we have a workaround. Just the same, this is not a confidence builder. Why, with transparent Syncthing software upgrades, should we expect a naive user to recognize the need and know how to clear browser cache? I’ve never been blocked in basic use by a Syncthing upgrade before, which is part of my confidence in the team, now shaken.

16

This is obviously a bug, not the intended behaviour :sweat:. It’s unclear whether the problem lies in Syncthing or in Firefox though. Chromium-based browsers don’t seem to have issues with the new login, and I have just tested Firefox with no previous cookies, and it also did open the GUI with no problems in such a case.

It seems that the issue may happen when you’ve already accessed the Web GUI in an older Syncthing version, and now you’re trying to access the newer one with the same Firefox browser.

17

Also, it only happened on the Windows Firefox, not the MacOS Firefox. Not fun debugging, but at least we’ve narrowed the scope. So your test case is on a windows box with recent Firefox, first viewing the gui for Syncthing v1.24.0, then allowing Syncthing to update to v1.26.0. What’s getting placed in cookies under Firefox/Windows, which differs (incompatibly) between v1.24.0 and v1.26.0?

18

Same issue by accessing a http debian webserver in the internet with google chrome. No problem in Google Chrome private window. No problem in Firefox. Testet on Windows 10, all apps and the OS updated to latest.

Updated from 1.25.0 to 1.26

No issues with Google chrome, Firefox or Edge on Android 11.

Hth

19

Confirming infinite refresh behavior in Vivaldi and Pale Moon (windows 10), both in tabs that normally remain open for monitoring. Syncthing on Debian (2 servers) and FreeBSD (3 servers)

SyncTrayzor on Windows 10 is working fine.

Ctrl-F5 did not help.

Clearing cookies for each site fixed the infinite refresh behavior.

Did not touch browser cache.

1 Like
20

The problem seems to be caused by /rest/events?limit=1 always returning 403 Forbidden.

The UI reacts with a reload of the UI.

Maybe here:

The question is how the browser is able to get past the login screen which is supposed to intercept this.

I’d be interested in the network log of such a broken session.

1 Like