The authz_policy.py sample is only a *sample*

[alristico@…]

I had some trouble with setting up a policy where the anonymous user could see only the front page of the wiki (wiki/WikiStart), but not the rest of the wiki without further authorisation through logging in. I used the authz_policy.py and had the following in the associated authz file:

[groups]
superdevs = me

[wiki:WikiStart]
anonymous = WIKI_VIEW

[wiki:*]
anonymous =

[*]
@superdevs = TRAC_ADMIN
anonymous = MILESTONE_VIEW, ROADMAP_VIEW, TIMELINE_VIEW

According to the docs in the authz_policy.py file, order of the directives mattered. The first directive should have allowed anonymous visitors access to the front page, while the second directive dissallowed anonymous browsing of the rest of the wiki. Instead, this resulted in an error:

No handler matched request to /wiki/WikiStart

I talked to "aat" on the IRC channel and he came up with the following:

the issue is that trac checks for access to AT LEAST ONE resource
in a realm by just checking if the user has the permission on <realm>

"aat" also provided a patch and stated that he would try and come up with something better soon.

Everyone seems to agree that someone should create a trac hack out of this. Anyone out there have copious amounts of free time for that?

[alristico@…]

Temporary patch file for authz_policy.py

[anonymous]

Darn, I just ran in to the same issue.. or similar. In my authpolicy.conf:

# view and edit a specific page
[wiki:DK]
betti = WIKI_VIEW, WIKI_MODIFY, WIKI_CREATE, WIKI_DELETE

# allowed to see the default page where a link to the editable page can be presented
[wiki:WikiStart]
betti = WIKI_VIEW

other pages and modules should get permissions "None", so nothing extraneous will be displayed.

But from here on things are quite inconsequent:

/

The WikiStart page is displayed and so is the link to the [wiki:DK] page. Fine!

/wiki/DK

Error: Not Found No handler matched request to /wiki/DK

/wiki/WikiStart

Error: Not Found No handler matched request to /wiki/WikiStart

/wiki

Error: Not Found No handler matched request to /wiki

It seem as if, to be able to display any URL starting with /wiki* (i.e. everything other than just "/") the wiki module thinks that you need WIKI_VIEW on [wiki:*@*]…which would kind of beat the purpose here.

[conny@…]

anonymous forgot to fill in my email ;-)

[Christian Boos]

The Error: Not Found No handler matched request to /wiki comes from the fact that the view permission is not granted for the whole Wiki realm. The authz_policy plugin should actually return True for this check, as soon as it knowns that at least one Wiki page is reachable. Otherwise, it should return None, leaving the possibility to other plugins to decide, or even False, if the authz_policy knowns that no Wiki page can be viewed.

See also #6211, which contains a discussion very relevant to the specific problem raised here, and r6188 which shows what a permission plugin is supposed to do in this case.

[digiqr+trac@…]

I have little question about authz_policy.py. Is it possible that authz_policy.py will use "groups" from Trac permissions? I have few groups like:

member1	_role1
member2	_role2
member3	_admin
_role2	_role1
_role1	some trac rights
_role2	additional rights
_admin	TRAC_ADMIN

I can't use _role1, _role2 or _admin in authz file, just only memberx. I must recreate groups in [groups] section, but is is uncomfortable.

[osimons]

Replying to digiqr+trac@gmail.com:

I have little question about authz_policy.py. Is it possible that authz_policy.py will use "groups" from Trac permissions?

No, it isn't. The main problem is that the groups gets expanded into the individual permissions, but there is no API for checking the groups (roles) of users or permissions against it. A number of tickets deals with improvements to the user APIs - notably #5648, #5425, and #2456. Scheduled for 0.12, so hopefully by then…

[conny@…]

For now, I could do without groups all in all - could only the sample AuthzPolicy do what it is supposed to do at least for users ;-)

[Dustin Spicuzza <dustin@…>]

Another problem with the authz_policy.py is that it does not support nesting groups within groups in the file specification, whereas SVN's authz does. I'm attaching a patch that fixes this.

[Dustin Spicuzza <dustin@…>]

Allows nested groups in authz group specification

[gw.trac@…]

Replying to osimons:

Replying to digiqr+trac@..:

I have little question about authz_policy.py. Is it possible that authz_policy.py will use "groups" from Trac permissions?

No, it isn't. The main problem is that the groups gets expanded into the individual permissions, but there is no API for checking the groups (roles) of users or permissions against it. A number of tickets deals with improvements to the user APIs - notably #5648, #5425, and #2456. Scheduled for 0.12, so hopefully by then…

Hm, a dirty workaround patch is in #7650 that Dustin just closed as duplicate of this. Actually it is exactly what digiqr wanted to have realized with the currently available API. It is not elegant and slow (you probably won't notice), but it works.

[Christian Boos]

anonymous permission definitions were also matching for authenticated users.

So in the example reported here, when checking the permission for a wiki page, the following:

[wiki:*]
anonymous =

was matching for the "me" user and the next setting:

[*]
@superdevs = TRAC_ADMIN

was simply not seen.

Fixed in [8786].