On Sat, Jan 18, 2014 at 4:02 PM, Jo-Philipp Wich <j...@openwrt.org> wrote: > Hi. > >> At the first sight the problem is solved: you open "System" tab and >> you don't see "LED Configuration" option, but as soon as you select >> one of the System's tabs all hidden tabs appear. >> >> How can I remove the tab permanently for the current session? Why >> removing the tab from tree (c, contect.dispatch) is not enough? > > I see no easy way to do that. > > The least invasive solution would be simply not rendering specific menu > points in the active theme's header.htm depending on the value of > luci.dispatcher.context.authuser. > > Note that this will only cosmetically disable tabs, direct access by > manipulating the url would be still possible. > >> >> Kiran has proposed some questions, that could lead to the solution >> of the problem, but I can't answe them myself so far: >> >> Are we sure that "c" (variable containing the tree) is the only >> source from which the page is rendered? > > It is. > >> Is the "c" created from the file or the cache. > > It is built by the cached index() functions from the controller files. > >> Is it created from the file for the first time and then from the >> cache on consequent accesses? > > The tree is never cached, only the functions building it are cached. > >> Why is it changing when I access different tabs? > > To cut down the amount of required processing work, only the subtree of > the current location is processed - see > http://luci.subsignal.org/trac/ticket/288 > >> Is the "c" tree created even when "sauth.user" is empty? > > Yes. > >> why? > > First of all, because one can have public menus / pages. > Furthermore the tree is built before the login state is even determined, > the authentication level is defined in the tree so you cannot perform > auth before the tree is built in order to influence the tree layout > depending on the auth, chicken-egg problem. > >> Is this structure cached then? > > No. > >> what is the difference between "context.tree" and >> "context.treecache". > > context.treecache is a weak temporary scratch table used to hold > implicitely created node objects during the tree building. > >> . Can we use it for access restriction? > > No.
Thanks for explanation. I've solved the problem of reappearing sub-tabs through replacing 'c' with 'ctx.tree' in remove_idx() call. But as you've mentioned, it is only a cosmetic fix. Direct access by manipulating the URL is still possible. I've updated my SO answer. Yegor _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
