On 1/19/2010 11:52 AM, Pedro Félix wrote:
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Christian Boos
Sent: terça-feira, 19 de Janeiro de 2010 08:57
To: [email protected]
Subject: Re: [Trac-dev] Permission group providers
On 1/18/2010 8:22 PM, Pedro Felix wrote:
Hi,
I'm currently developing a plugin with a component implementing
IPermissionGroupProvider, to provide groups based on OAuth WRAP
tokens
received in the request's headers. In this context
1) When is the get_permission_groups method called? In every
request?
No, only once in a while, see
trac.perm.DefaultPermissionPolicy.check_permission.
Also when called explicitly in a few cases (e.g. restrict_owner).
1) This refers to the fact that the permissions are cached? However, when
the cache expires, the
"PermissionSystem(sellf.env).get_user_permissions(username)" statement will
alays result in a call to the group provider. I'm I wrong?
No, you're right. However that cache will only be used for
"coarse-grained" permissions.
That is, the other permission policies won't be able to access the group
information, at least not in a convenient way.
2) How can I access the request info? Is the mod_python Request
object available?
No, on purpose, the idea here is to dissociate the authorization from
the authentication, therefore the permission system only needs to
consider the username.
3) I do not completely agree with this, because "authentication" does not
only mean obtaining the username. Consider for instance federation scenarios
where the authentication is based on security tokens (e.g. SAML assertions,
WRAP's SWT tokens), associated with the HTTP request, that convey not only a
username but also additional attributes such as roles or capabilities. The
authorization sub-system needs this extra attributes to make the
authorization decision. In extreme cases, the username value may even not
exist, since all authorization decisions are based solely on roles present
in the security token.
Perhaps, but I think that's far beyond the security model chosen for
Trac. It should eventually be possible one day to enable the permission
checks outside of the context of a web request, for example within
scripts using trac-admin (#5566). In our case, if we have role or
capabilities, it's done via group membership and eventually in the
future via the relationships between the user and the resources (things
like "reporter", "author", "owner", see
http://trac.edgewall.org/wiki/TracDev/Proposals/EvenFinerGrainedPermissions).
-- Christian
I'm thinking in addressing this issue via a IPermissionGroupProvider that is
also a IRequestFilter, so that it can access the request information.
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
