On 5/26/09 3:52 AM, Wichert Akkerman wrote:
> Previously Chris McDonough wrote:
>> def remember(self, principal, token):
>> """ Return a set of headers suitable for 'remembering' the
>> principal on subsequent requests """
>> def forget():
>> """ Return a set of headers suitable for 'forgetting' the
>> current user on subsequent requests"""
> It would be nice if there was also a handy utility function to apply
> those headers to a response. I suspect that code is often repeated now.
>> class IAuthorizationPolicy(Interface):
>> """ An adapter on context """
>> def permits(self, principals, permission):
>> """ Return True if any of the principals is allowed the
>> permission in the current context, else return False """
>> def principals_allowed_by_permission(self, permission):
>> """ Return a set of principal identifiers allowed by the
>> permission """
> There are situations where principals_allowed_by_permission may not be
> possible, or at least very expensive. In LDAP/AD environments for
> example getting a list of all principles is often not doable. This
> should be reflected in the API somehow. Perhaps allow for
> principals_allowed_by_permission to return a value indicating it is not
> willing to support this?
I don't think principals_allowed_by_permission does what you think it does. Or
at least what I meant it to do. In a traversal-based app, it's essentially a
walk of the object ("model") graph from the root along some path to a
context collecting identifiers for users who "have" that permission.
In an ACL-based system (such as the default ACL policy in BFG), this means
there's some ACE stored on a node in the path that allow the principal that
permission, and and no nodes in the path that have an ACE which explictly
the principal that permission.
"Principals" in this sense are just strings in ACLs, usually. We never
talk to the "authentication source" during this process; all the info is stored
in the model graph.
> The same holds for the version in ISecurityPolicy.
ISecurityPolicy is now dead; its functionality is covered by function APIs such
as "has_permission" which coordinate asking the authenticator and authorizer
the right info.
> I wonder if we should also set the exceptions that can be thrown by
> those routines. Depending on the implementation that can be DB-API
> exceptions, LDAP exceptions, or anything else which would mean that
> people using this API will end up have to use a bare try/except.
Can you provide an example situation where some system wasn't up to this task?
Repoze-dev mailing list