First of all, thanks for the reply. Regarding Christian's reply, see below.
Thanks Pedro > -----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? > But there are a few problems with IPermissionGroupProvider, see below. 2) This refers to the fact that the group providers are called by the DefaultPermissionStore. If a new permission store is used, then the group providers will not be called? > > > 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. I'm thinking in addressing this issue via a IPermissionGroupProvider that is also a IRequestFilter, so that it can access the request information. > > > I've already looked in the Trac developer wiki, however the > > information regarding these issues is rather scarce. > > > > See http://trac.edgewall.org/ticket/5648 which summarizes the issues > with groups. > > -- Christian
-- 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.
