I just tried it with OpenWrt SNAPSHOT r18244-101300b842 (https://downloads.openwrt.org/snapshots/targets/x86/64/openwrt-x86-64-generic-squashfs-combined.img.gz) in Qemu (just opkg update; opkg install luci-ssl) and Brave Browser Version 1.32.113 Chromium: 96.0.4664.45 (Official Build) (64-bit) on Debian 11 and have no issues logging in.
Can you try to export the entire login request as HAR ?
Before pressing "Login", F12 to open the debug console, select network tab, press "Login" on the web page, right click the first luci/ request, "Copy all as HAR". Careful, the HAR will contain sensitive data such as the password you've entered. Copy it into a text file and redact it before sending. Feel free to PM it to me if you do not want to post it here.
Can you please repeat the process after checking the [x] Preserve log checkbox in the network monitoring tab?
Thanks. So the login is working fine, a session is cookie is received but when the login code calls location.reload() to reload the page after login, the browser does not send the previously received sysauth cookie, it is simply omitted, so that you're thrown back into the login dialog.
Maybe some new crappy WebKit heuristic or security measure. Will research. Unfortunately I am still not able to reproduce it locally.
Thank you. If you have some ideas to try out, you can always send me a patch and I'll be happy to test it on my router.
Hi, any updates on the issue? Were you able to find out the source?
Unfortunately I was neither able to reproduce it, nor was I able to find similar instances in the web and thus I can't offer any specific things to try.
Maybe some nonstandard add on, proxy, anti virus appliance or similar is interfering?
well found an odd way to 'fix it' (read: temporarily resolve the glitch)...
some spammy/overloaded sar/har if any use... grepping headersSize on the failed one (number 1) possibly yields a few -1 ? but really out of my depth here so likely nothing...
faulty logic seems to happen right before the 'luci/' is sent... but that could be just a symptom of no cookies or whatever...
laymans guess something with the way css interacts with header timing... (note: neither bootstrap-light nor bootstrap-dark were selected just the normal bootstrap)
Thanks. Well, I am using Brave. I cannot login using the Private Window, if this is what you meant?
apologies... I'd seen almost duplicate symtomatology... so thought more meta-data in the mix would assist in fault finding...
feel free to disregard my input...
Well the current bootstrap theme in master uses a JavaScript modal overlay for the login dialog, the username and password values are sent as FormData via XHR to the router, the router replies with the normal page (including a Set-Cookie: sysauth... header). This response is discarded by the JavaScript and a location.reload() is triggered instead to reload the entire page after login.
For some reason some browsers under some circumstances (which I couldn't figure out since it works for me on all my devices) do not "take" the sysauth cookie offered via Set-Cookie in the XHR reply and load the page without any cookie after location.reload() which then will trigger the login again, etc.
Edit:
Maybe you can try the following change on your affected devices:
diff --git a/themes/luci-theme-bootstrap/htdocs/luci-static/resources/view/bootstrap/sysauth.js b/themes/luci-theme-bootstrap/htdocs/luci-static/resources/view/bootstrap/sysauth.js
index 344b043a36..dbc1e4fc57 100644
--- a/themes/luci-theme-bootstrap/htdocs/luci-static/resources/view/bootstrap/sysauth.js
+++ b/themes/luci-theme-bootstrap/htdocs/luci-static/resources/view/bootstrap/sysauth.js
@@ -92,7 +92,7 @@ return view.extend({
Object.getPrototypeOf(L).notifySessionExpiry = function() {};
- return request.post(location.href, fd).then(this.handleLoginReply, this.handleLoginError);
+ return request.post(location.href, fd, { credentials: true }).then(this.handleLoginReply, this.handleLoginError);
},
addFooter: function() {}
Sed oneliner to hot-patch on the router (assuming minified JS):
sed -i.bak -e 's#request.post(location.href,fd)#request.post(location.href,fd,{credentials:true})#' /www/luci-static/resources/view/bootstrap/sysauth.js
After applying it, clear cache and retry.
There have been similar login issues with luci-theme-bootstrap on 21.02.x builds as well that seem to be most problematic after flashing a new build. So it really affects being able to set the password initially.
Could you please send this fix (if possible) to the 21.02 luci branch as well?
This sounds like the usual HTTP sysauth cookie is not allowed to overwrite yet existing HTTPS sysauth cookie issue, unrelated to this particular problem here.
This fix addresses changes which weren't added to 21.02 yet.
This didn't work for me.
But this worked! Is it possible to bring this patch to master?
It already is.
Thank you sir! May you have a great weekend!