luci-base: menu and i18n plays very BADLY with sysauth=false in master

[hmh]

LuCI pages with sysauth=false (e.g. status pages that should work even for an user that is not logged in) are broken on LuCI master.

The symptom is that when you access the page with "sysauth=false" attribute, the menu disappears, as in: not even nodes that are also sysauth=false show up.

What should happen: the menu should list all pages, always, and require authentication if you try to access one of them while lacking the required credentials.

Translations are also broken, and doubly so:

1. They try to XHR something from a node that is below /admin/, even if you are on a node on an entirely different subtree (like say, a /status node that should work unauthenticated and be the first page the user gets when he connects to the modem).
2. Whatever the translation stuff tries to fetch is hiding behind a sysauth=true node, which renders it useless for any sysauth=false page [if the user is unauthenticated]

Maybe the /l10n/ or /i18n/ namespace (or even wherever luci-static ends up) should be used for anything the i18n mechanism needs? It really doesn't make sense to have it tied to /admin/.

[hmh]

I am extremely impressed with the response time! THANK YOU!

[hnyman]

This change apparently makes the whole menu structure browseable even before logging in.
I am not sure if that is wise, as that exposes knowledge about the installed package universe to the casual browser. (E.g, in netcafe context)

[jow-]

I had the same thoughts but eventually the entirety of LuCI will be moved to the client side and then this knowledge can be easily obtained by checking for specific files in /luci-static/ even when not authenticated.

[hmh]

Well, if you want to hide pages unavailable to the current authentication state (which MUST NOT depend on whether the user is in a page that requires authentication or not!!!!), you MUST have a way to access the authentication page.

The fact that it was working before was just accident, but it made the design defect less obvious: it would hit a page that requires authentication, with no way out (which is already broken: the menu would NOT show anything, not even pages that don't require authentication).

I am not sure what is the best design fix for this, but it isn't difficult to fix, here's an example:

1. Whether a menu node is show or not would depend on the intersection of that node's auth requirements and the current auth state. If non-empty, show it. Otherwise, don't show it.

2. There would be a menu node type that is always available when logged out, and which allows one to log on by redirecting to whatever landing page is desired (which would trigger the logon page). This node would get hidden when the user is logged in.

alternatively, just have the /admin node be an active node that doesn't require authentication, always show up on the menu, and redirects to firstnode() -- this would trigger the authenticaton.

That should be enough.

PS: edited with a simpler, better solution than the first one I wrote in the comment. twice :(

[sanitariu]

I think closed but unlocked door is much much better than open and unlocked door.
Hnyman there is nothing wrong when you admit that the commit is more bad than without it.
You can easy fix this.

[sanitariu]

.... and most important it is UGLY.....

[hmh]

The real issue you guys have seems to be a want for "privacy" of the menu tree.

The only way to do this is to filter the menu tree on the "embedded-device-side". Nothing else will work on openwrt-20 (trunk): it renders the menu client-side, by sending all menu notes to the browser and running some javascript to change it into html5.

Reverting this patch is NOT going to change anything re. privacy of the menu tree in openwrt-20.

As for filtering the menu tree "server-side" (in the router) before sending it to the java-script, that was my proposal for properly fixing the design behind this issue -- but I don't have the time nor the inclination to implement that, so if nobody steps up to do it, you cannot complain that the main LuCI devs don't care.

And there WILL be side-channels that will leak that information. Someone mentioned they wanted to hide that package foo was installed. You have to either disable, or redesign the i18n entirely, or it will leak the presence of translated strings for that package. And rpcd list. And...

NOTE: I am not one of the "main LuCI devs".