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.
> > 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).
Wichert.
--
Wichert Akkerman <wich...@wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
_______________________________________________
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
