Login to Luci interface does not work in Chrome/Brave, Firefox ok

Installing and Using OpenWrt
1

Hello,

I have installed latest snapshot just now and I am unable to access Luci via web interface anymore with Chromium-based browsers: Chrome or Brave. It works with Firefox, though. Tried clearing cookies and cache completely as a possible solution – does not help. Any ideas?

# ubus call system board
{
	"kernel": "5.10.82",
	"hostname": "OpenWrt",
	"system": "ARMv7 Processor rev 0 (v7l)",
	"model": "Netgear Nighthawk X4S R7800",
	"board_name": "netgear,r7800",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "SNAPSHOT",
		"revision": "r18244-101300b842",
		"target": "ipq806x/generic",
		"description": "OpenWrt SNAPSHOT r18244-101300b842"
	}
}

Web console shows the following error:

​GET https://myrouter/cgi-bin/luci 403 (Forbidden)

​handleLoginReply @ /luci-static/resourc…327.65538-e982c05:3
Promise.then (async)
handleLogin @ /luci-static/resourc…327.65538-e982c05:4
eval @ /luci-static/resourc…7.65538-e982c05:304
eval @ /luci-static/resourc…327.65538-e982c05:3
2

Interesting. I can't get it to work with firefox but it works from microsludge edge and chrome on android.
Tried deleting cookies, cached pages witj no change. It brings up the logon screen, accepts the logon ok (according to the system log) but return me straight back to the logon prompt page.
This is on the latest snapshot. OpenWrt SNAPSHOT r18244-101300b842 / LuCI Master git-21.327.65538-e982c05

I was only using the http url, not https so don't know if it is related.

1 Like
3

You have installed a snapshot image. Read the link for instructions how to install Luci, which is not installed by default in snapshots.

4

I installed an image built with imagebuilder that included luci and uhttpd which is why I could connect with two different browsers, just couldn't with firefox.
The OP had a similar issue except that in his case it was Chrome/Brave that didn't work but firefox did.
So I very strongly suspect that the installed images weren't suffering from missing luci and/or uhttpd. :wink:

5

My answer was more directed to @aeigus .

6

@tmomas
He does mention that his issue is with chrome or Brave and that Firefox works, I read that as luci is installed. I may be mistaken though.

1 Like
8

Delete the sysauth cookie and it should work again. This usually happens when the previous installation was HTTPS and now login is attempted via HTTP. The HTTP-emitted sysauth cookie is not allowed to overwrite the stale HTTPS one in this case.

9

I guess it means there's no relation between https/http, but there's definitely something flimsy going on with latest Luci updates...

10

It does not work. I've deleted completely ALL cookies, restarted Brave and ran in incognito/private mode afterwards – and it didn't help.

11

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 ?

13

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.

14

Thank you for the help, @jow. Below you can download the redacted HAR file I have created:

https://www.andrews.lv/share/router/myroter.har

15

Can you please repeat the process after checking the [x] Preserve log checkbox in the network monitoring tab?

16

Done. https://www.andrews.lv/share/router/myrouter.har

17

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.

18

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.

19

Hi, any updates on the issue? Were you able to find out the source?

20

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?

21

well found an odd way to 'fix it' (read: temporarily resolve the glitch)...

  1. login in incognito window
  2. switch to argon (probably any other also if you don't have this theme) theme
  3. go back to normal window
  4. login and change back to bootstrap
  5. logout and login again....

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)

22

Thanks. Well, I am using Brave. I cannot login using the Private Window, if this is what you meant?

1 Like