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
the
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"
(e.g.
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.
Thanks!
- C
_______________________________________________
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
