Yes. Problem will be only if autorize and save login and passvord in browser , next close all tabs linkin with 192.168.x.1 and next open at least one tab 192.168.x.1. If leave open last open tabs and open next tab with 192.168.x.1 all will be good. However so will be only till as will be open one tab 192.168.x.1. If in browser not save login and password - problem not will arise. Because you everytime be autorizing and OpenWRT 19.07 will be work normaly.
Perhaps something is getting lost in translation here, feel free to post a reply in your native language (with an English translation)...
- What causes you to perform these sequence of events?
- Why do you need to perform them to run the router?
- Are you saying your issue is with the saved login (which I observed from your video some days ago)?
- Are you saying that you expect LuCI to stayed logged in, on previously logged out pages - without re entering credentials?
It really sounds like this is an issue with opening multiple tabs...I only have problems like this when I still have an old tab open.
1 Like
I get this error message URI malformed always after following steps on OpenWRT 19.07.2.
Using Firefox mobile version 68.8.0 on Android 8.
Step 1 with a cleared cache beforehand. Normal login. Default the Status page is shown. All fine.
Step 2 close Firefox (but NO logoff from LUCI and NO closing of the Firefox Tab)
Step 3 restart Firefox...The non-closed Tab reopens automatically with the last OpenWRT URL and the red line with URI malformed message appears.
This bug , lasts long and not fix ?
I'm lost at why you would still call this a bug, when it's clear that the user failed to log out from the browser; and you stated and showed that you open lots of tabs at once for no functional reasons?
Is this a Confirmation Bias?
No error would occur if the user cleared the cache before browsing to LuCI (step 3a); then performed the Step 3b by browsing to LuCI.
You're asking OpenWrt to allow a 3rd party to return to the machine, reopen the tab and have access to LuCI - without entering a password!?!?! 
You don't see a security risk in that???
Are you saying that you want to remove the password from LuCI in your use cases???
NO! I sayd what bug there is.
If you think what need logout always , need do timeout afeter whom will be automaticly logout.
If this not maked , I will be say what this bug.
Because this will be if I easy reopen luci in next tab faster or small delay.
LOL, OK. You described a "bug".
You do understand you must close ALL old tabs, correct?
That's the only issue I saw in your case (i.e. failure to close all old tabs), aside from your opening the new ones very fast.
Yes, OpenWrt also has a new timeout for the login, is this your issue???
Are you asking for the timeout to be removed; or how to change the setting?
Why you try make fun of problem ?
I say and I will be say till you not understand what this BUG and ONLY BUG. Fast or fastest reopen tab or tabs - this normaly. In 18.0x all work normaly , in 18.0x such have timeout and about 3-5 minutes if I reopen tab 192.168.0.1 I see settings without errors. In 19.0x I can reopen tab 192.168.0.1 , I can to get settings and I can replace settings , but I before that will be error. However if I click on status and select any paragraph I open all normally. Why you this deny ?
I'm not. I'm asking why you leave old tabs open, open new ones really fast, then get an error you call a bug?
Please show us this error (i.e. you're unable to make changes to settings) with only ONE tab open to LuCI. Thanks.
Then that was a security bug!
I've never successfully reopened LuCI after a logout or timeout - without a password.
Heck here, where I sayd what open LUCI after logout and can open per IP address without login on 18.0x?
I always say what if I close tab without logout and open 192.168.0.1 so , I correctly view setup.
You for some reason try say , what bug is not bug.
At all here , besides speed limit , me not help not with anything.
I sayd about bug in interface - to me say what this normaly and fix not will be.
I sayd about bug in recive IPv6 - this also ignored and not fix bug. However I can recive IPv6 if ping 10 ms and more. But as do so that would router do reconnect till not recive IPv6 - to me not sayd.
Here:
Apologies if I misunderstood this, can you be more clear?
Feel free to respond in your native language.
Close tab...or CLOSE BROWSER??
@peterstamps closed his browser, so you agree this is another issue and unrelated to your "bug". 
Regarding tabs - I noted that I see this error after opening multiple tabs, so we agree:
While I agree the error appears, I honestly see no functional reason to open multiple tabs - like you did in your video. Please describe the use case.
See: 
So, it's clear you were just loading tabs, you even made a video.
So, simply show the issue, with one tab - and then someone can identify and confirm the problem too. Simple.
If I open 192.168.0.1 login , and next fast close this tab without logout and open tab again - I see this bug. I say, help not will be this I understand.
1 Like
This report is extremely confusing. Despite numerous attempts I fail to reproduce it. How do you "fast close" a tab and open it again? Do you use some kind of shortcut?
- open 192.168.0.1 or 192.168.1.1
- login in this tab
- close this tab without logout
- delay 30-60-90 sec and retry open 192.168.x.1
- if normally , close this tab without logout
- retry open 192.168.x.1 after 120-160-180 sec
In this process use only FireFox 7x.x e.g from 70.0 to 75.0.
It seems to me the result of a kind of time-out issue (maybe a check that is wrong programmed/finished??).
It appears randomly, but most often on the latest Firefox Mobile client for Android 8, but I got it also on Windows 10 Firefox (latest version as well), but not also repeatable.
I use HTTPS connections only ---> could it be related / caused by the certificate check?
Just thinking loudly to trigger idea's.
The SyntaxError bar automatically disappears once the page is completely loading.... another potential hint!
Anyway just anoying.....
Of course logout is a normal way to go, but simply closing the Firefox app on a well protected mobile should be okay as well... I am refering to other remarks.
Sometimes I get also other error messages (something with .js execution) but it skips fast and I cannot capture it or properly read / remind the content.
Dear team,
I actually can reproduce the issue the topicstarter is having. I am currently using Firefox 104.0.2 on Windows 11. The issue seems to be related to automatic logout upon some time of inactivity. What actually happens:
if you open a router IP without anything - no issues at all. If you've left an open tab with some OpenWRT page opened except for mainpage for some time that the logout happened (and there is no clear indication it did logout you anyways 
) and then click on random menu item then you'll get a prompt to re-login. You click, login form opens, then you try to authenticate and boom - the message that URI os maiformed appears. Even more, when you try to click on any menu item the infinite load starts. You have to manually refresh the page and you appear logged in - everything works. So basically the URI mechanism seems to be broken after the automatic logout happening.
I assume this may be a bug - I tried that on a clear new profile without any extention and that did happen.
My proposed solution if this can be classified as a bug (as I mentioned I would suppose it is) is - easy fix? - maybe if the automatic logout happens the automatic page reloading may solve the issue. On the other hand, more proper solution of fixing the URI malforming is definitely a better one - however I am not the one to tell You how you can fix that
@Eugeniusz - are you working with OpenWrt 19.07.x? If so, some things to know:
- The entire 19.07 series is EOL and will not see any fixes whatsoever.
- Versions current and supported as of this moment: It is recommended that you move to 22.03.0 (recently released) or 21.02.3.
- If you must run 19.07, upgrade to 19.07.10 (release notes) for the most up-to-date (and possibly fixed) version. Beyond that, 19.07, as stated earlier, will never be upgraded
The malformed url issue has been tracked at https://github.com/openwrt/luci/issues/3747
The fix was backported to 19.07.
2 Likes