On Sat, Sep 26, 2009 at 3:59 PM, Chris McDonough <chr...@plope.com> wrote:
> 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
>>> 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 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 repoze.who.security import effective_principals
> principals = effective_principals(request)
> username = principals
> 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
Thanks for the response Chris,
This makes perfect sense. And honestly I'm not married to repoze.who
or repoze.what, To me it was the best option in pylons which is why I
had it lying around.
/purge from brain who+what
Thomas G. Willis
Repoze-dev mailing list