Hi,
One of our admins spotted this, not sure if a bug or feature, so not submitted it (yet) to the bug tracker.
If you drill down, as an Authenticated User, into
Machine Tracker / MAC Search / MAC Search results
and then click the (details) link for an interface you are jumped into the /ipdevinfo code, and taken out of the main browse/report code.
Since the default permissions for an Authenticated User does not include ipdevinfo, the user gets a permission denied :(
I think the (details) link should take you to a link like
/browse/b59-l2-cat1/module3/port1846/
rather than one like
/ipdevinfo/b59-l2-cat1/module=3/swport=GigabitEthernet3/0/44/
but I assume this has been done in part to test the ipdevinfo beta code? Both pages seems to serve a similar function, one the old way, one (I assume) the new way under development? (The ipdevinfo page doesn't have the Cricket links in place yet)
The problem is that Authenticated Users hit this permissions issue, but if we try to add |ipdevinfo| into the web_access permissions, it doesn't seem to resolve the permissions problem.
Is that link to the newer stuff intended? If so, how should we correct the permissions problem?
Thanks :)
On Fri, 2008-08-22 at 15:13 +0100, Tim Chown wrote:
but I assume this has been done in part to test the ipdevinfo beta code? Both pages seems to serve a similar function, one the old way, one (I assume) the new way under development? (The ipdevinfo page doesn't have the Cricket links in place yet)
Your assumption is correct. The link in question was only recently added, and thus pointed to the new /ipdevinfo/ instead of the old /browse/. Hopefully, ipdevinfo will be ready enough for NAV 3.5 in September to point all other old /browse/ links to ipdevinfo too.
The problem is that Authenticated Users hit this permissions issue, but if we try to add |ipdevinfo| into the web_access permissions, it doesn't seem to resolve the permissions problem.
The fact that ipdevinfo have not been added to the privileges table is, however, a bug. The following SQL query seems to fix the problem at our development installation of NAV:
UPDATE accountgroupprivilege SET target = '^/(preferences|status|navAdmin|report|browse|stats| cricket|machinetracker|ipinfo|l2trace|logger|alertprofiles| ipdevinfo)/?' WHERE target = '^/(preferences|status|navAdmin|report|browse|stats| cricket|machinetracker|ipinfo|l2trace|logger|alertprofiles)/?';
Is that link to the newer stuff intended? If so, how should we correct the permissions problem?
Let's just correct the permissions problem. I'm about to update the SQL scripts, so we won't forget this for NAV 3.5.0. Please do file a bug report on this. A bug report would help us remember to include the permissions fix if a 3.4.3 release comes before 3.5.0.
On Fri, 22 Aug 2008 16:53:07 +0200 Stein Magnus Jodal stein.magnus.jodal@uninett.no wrote:
UPDATE accountgroupprivilege SET target = '^/(preferences|status|navAdmin|report|browse|stats| cricket|machinetracker|ipinfo|l2trace|logger|alertprofiles| ipdevinfo)/?' WHERE target = '^/(preferences|status|navAdmin|report|browse|stats| cricket|machinetracker|ipinfo|l2trace|logger|alertprofiles)/?';
Is that link to the newer stuff intended? If so, how should we correct the permissions problem?
Let's just correct the permissions problem. I'm about to update the SQL scripts, so we won't forget this for NAV 3.5.0. Please do file a bug report on this. A bug report would help us remember to include the permissions fix if a 3.4.3 release comes before 3.5.0.
The simplest way (and least intrusive) way of adding the permission to a running NAV installation is to add a new web_access privilege to the following regex pattern: ^/ipdevinfo/?
That is also the only useful way to automatically update the permissions while upgrading to the next release, Stein Magnus. Upgrades should not touch existing privileges, only add new ones.
On Thu, 2008-08-28 at 15:01 +0200, Morten Brekkevold wrote:
The simplest way (and least intrusive) way of adding the permission to a running NAV installation is to add a new web_access privilege to the following regex pattern: ^/ipdevinfo/?
That is also the only useful way to automatically update the permissions while upgrading to the next release, Stein Magnus. Upgrades should not touch existing privileges, only add new ones.
On second thought, this is rather obvious and clearly the best way. I've just changed the trunk.sql upgrade script in the ipdevinfo branch to insert a new privilege instead of updating the old one.
-
Morten Brekkevold -
Stein Magnus Jodal -
Tim Chown