Thomas G. Willis wrote:
>>> I was wondering if anyone is aware of an example that shows how to
>>> link repoze.what to an aclauthorzationpolicy .


>>> I have some who/what plugin bits (WhoPlugin, GroupSource and
>>> PermissionSource) I wrote that I would like to use, and preferably
>>> using an ini file for configuring repoze.what.

Sorry, I realize it's a confusing situation, but repoze.bfg requires neither 
repoze.who nor repoze.what.  repoze.bfg actually has machinery inside of it 
that "competes" with some repoze.what features (in particular, pluggable 
authorization policies).  For this reason, no one has ever tried this 

>>> There's a good chance I am missing something obvious, please be
>>> gentle.
>> Do you mean with bfg? I would love to see a bfg equivalent of Gustavo's
>> repoze.what-pylons example app and quickstart. I think that would go a
>> long way to increasing bfg adoption. BFG's roll-you-own nature makes
>> great docs even more important and I think Chris et al have done a
>> fantastic job in that regard, but I gotta admin I hit the wall when it
>> came to repoze.who/what. The system is great, but there is a *lot* to
>> digest to get it working.

My opinion: if you use BFG, forget what you know about r.what.  Just use the 
existing ACL authorization policy, or if that doesn't work, write a different 
authorization policy instead and plug it in using ZCML.

Sparse instructions exist in the security chapter for writing another security 
policy.  It essentially means writing a class with the following interface that 
"does the right thing" (whatever that might be):

class AuthorizationPolicy(object):
     def permits(self, context, principals, permission):
         """ Return true if policy permits access, false if not """
     def prinipals_allows_by_permission(self, context, permission):
         """ Return the set of principals granted the permission named
             'permission' in based on the supplied context """

"context" is the traversal context, "principals" is the list returned by 
"effective_principals", and permission is the permission name.

Then you can activate it by putting something like this in your ZCML file 
pointing to the policy:


If you do this, make sure to not have an "aclauthorizationpolicy" directive in 
the ZCML too.

> Yes with bfg. for example....
> gives the details for setting up a repoze.who authenticationpolicy
> (though I think I could use the remote user one too)
> but....
> <repozewho1authenticationpolicy
>  identifier_name="auth_tkt"
>  callback=".somemodule.somefunc"
>  />
> but the callback arg doesn't make sense if you already have a
> GroupSource and PermissionSource configured via repoze.what. But not
> putting a callback in makes the policy assume the user belongs to no
> groups. I think repoze.what ties permissions to groups, so if user
> belongs to no groups then no permissions? Furthermore, I don't have a
> callback to put there, it's all config driven.

BFG was really never meant to be used with r.what.  If you have enouh gumption, 
you could probably write a BFG authorization policy implementation that used 
existing r.what stuff.  I don't know how to do this, though.

> As far as I could tell, repoze.what doesn't seem to provide a way to
> get at the groups for the current request, but I could be wrong here.
> But even if I could get the groups back, how would I wire in the
> PermissionSource for acls?

from import effective_principals
principals = effective_principals(request)
username = principals[0]
groupnames = principals[1:]

> I still feel like I'm missing something obvious. But I was hoping to
> get this working because I rather like having the perms configured in
> the zcml rather than in decorators/predicates on specific functions.
> Other than that, thank you to those responsible for bfg. I'm really
> digging it despite these little hurdles.

- C

Repoze-dev mailing list

Reply via email to