On 5/26/09 4:16 AM, Wichert Akkerman wrote:
> Previously Chris McDonough wrote:
>> 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 
>> particular
>> context collecting identifiers for users who "have" that permission.
> Ok. I see the difference here: you use the proper definition of
> principals, why I mentally had expandede groups to turn it into a list
> of users. That requires access to some storage, while just generating a
> list of principals does not. I agree that using proper principals here
> makes sense, and makes my point obsolete.

Ah, right.  No.  The ACLs contain all necessary principal ids; no authorization 
policy's principals_allowed_by_permission function should ever need to go to 
authentication source.  FTR, the primary function of 
principals_allowed_by_permission is to be able to compute a set of principals 
that "have" some permission on an object for storage in a "security index" 
CMF's AllowedRolesAndUsers index).  The IAuthenticationPolicy thingy is an 
adapter, so it uses its context as the "current" object for that purpose.

That said, once some application gets a list of principals from 
principals_allowed_by_permission, that application might need to expand one of 
them into a different set (e.g. expand "group:foo" to its constituents), but 
that's outside the scope of this thing, thankfully.

>>> 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?
> A common one are transient errors, such as a connection failure during a
> database restart. LDAP can be difficult since it will raise an exception
> if a search would return more than a fixed limit of results (often set
> to 500). AD environments, especially with forests, may not allow you to
> query the list of principles at all (which makes sense, there can be
> many tens of thousands of principles).

Yup; ostensibly we won't need to worry about that here.


- C
Repoze-dev mailing list

Reply via email to