today syncthing v1.25.0 was upgraded to 1.26 from https://upgrades.syncthing.net/meta.json
I was not able to log in there via web gui. I have simple user/pass. Is it something wrong in my configuration ? 1.25 is working fine
Same here. Was prompt for upgrade 1.26. Since, no able to access web GUI. I have authentification and then, it load. And reload. And reload. And reload. So i can’t access settings or something else…
I’ve tried to uninstall / reinstall, same issue.
1.25 was working fine too.
Try shift+f5 and deleting cookies.
1 Like
Sorry, i was just seeing this post : Can't access v1.26.0 on localhost - #13 by ydhirsch
I’ve cleared cookies and it load again. Thanks !
Same login problem after update. What to do on Android?
It’s still unclear how to deal with this on Android, unfortunately. The only surely working solution seems to be to use the in-app app option to back up your Syncthing config, and then clear the app data (or uninstall and reinstall the app completely) and configure the app from scratch (using the backed up files to restore your Syncthing config).
Android problem remained.
I did an uninstall / install. I made a database delete. I imported the config.
Database delete won’t do anything but it’s very surprising that reinstalling the app hasn’t helped. Can you post a screenshot of what you’re seeing exactly?
Edit:
Just for the record, I’ve tried reproducing this myself by opening the Web GUI in an older version first, and then updating the app to v1.26, but in my case, the Web GUI just opens normally. I’m testing this on a real device running Samsung Android 11. This means, unfortunately, that I can’t do any debugging locally.
We desperately need a reproducible case for the regular web browser. Once we know why the web UI doesn’t work, we can ship the fix for the Android app.
What is your Android device specifically and what version of Android does it run?
Android 12 system
What do you mean by “Android device specifically”? Where can I see it?
The exact model name of your phone (e.g. Samsung Galaxy S23) or at least the name of the manufacturer.
Black Shark 5
I wonder if we should clear the cache programmatically before loading the web UI.
There is no real network access which means we don’t get hurt by non-cached assets.
Edit: we can also specifically clear the cookies
Cache cleared, problem solved, thanks for the help.
I thought I’d take this opportunity to create an account so that I can thank everyone involved in this wonderful project. Thank you :).
I have no problems accessing Syncthing on PC from any browser on Windows 11.
But I have the same ban - trying to access Syncthing app installed on Synology NAS.
To access Syncthing on Synology NAS, you access the NAS via any browser with login and password, then launch the Syncthing app installed on the NAS by calling it directly or via a shortcut on the desktop. This is where by entering my login and password I am denied access due to an incorrect user or password.
I managed to reproduce this reload-behaviour at least.
What tends to happen is that cookies with the same name are created per path (/, /rest, etc.), this doesn’t seem to happen in normal sessions, but we read cookies with a function which does the following: If multiple cookies match the given name, only one cookie will be returned., so I assume that it doesn’t always return the same cookie if multiple exist.
After removing 11/12 cookies with the same name (but having different path attributes), the reload stops and it seems to work fine again. Why these cookies are being made I don’t now though. If it’s expected behaviour I don’t know either.
2 Likes
This could be a sideeffect of creating the cookie based on the presence of the basic auth header?
Anyone still suffering from this could try the 1.27.0-rc1. Though I expect much of it will have resolved itself in the meantime due to sessions going away and cookies being cleared…
1 Like