Am 28.05.2014 08:20, schrieb Bert JW Regeer: > > On May 27, 2014, at 23:20 , Gerhard Schmidt <[email protected]> wrote: > >> On 27.05.2014 18:22, Tres Seaver wrote: >>> On 05/27/2014 10:20 AM, Gerhard Schmidt wrote: >>> >>>> Maybe I'm doing the whole thing wrong and there is a better way to do >>>> this. >>> >>> Use the a 'request.has_permission' check to filter the suboboejcts, e.g.:: >>> >>> alllowed = [x for x in context.getClubs() >>> if request.has_permission('view', x] >> >> That one has the same Problem. >> >> The context loss here is at pyramid/security.py line 387 says >> principals = authn_policy.effective_principals(self). >> >> So again only the principals of the root container are return and passed >> in the next line to >> authz_policy.permits(context, principals, permission) >> which fails because the group define in the context is not in principals. >> >> The problem is that the authentication policy is not context aware. > > > effective_principals(self) > > returns a list of effective_principals according to the authentication policy > and has nothing to do with the root context/container. > > If your effective_principals returns: > > group:admin, group:mods, group:staff, username > > And your context has: > > Allowed -> group:admin -> view > > Then request.has_permission(‘view’, x) will return True. > > Otherwise the user clearly doesn’t have view permissions because they aren’t > in the right group, or any groups at all, and thus False will be returned.
The user has the permission. going to the view works. the application is traversal based. Rootcontainer ACL allows everybody to view the default view which we are talking about. subobject1 ACL allow users who are in group group:users to access default view. which users are in group:users is define is subobject1 not in the root container. the authentication callback defined in authentication policy is aware of local defined groups an scanns the linage of the context for such groups. therefore if someone surfs to /subobject1 everything works fine because the context in the request object is subobject1 and effective_principals returns all principals of the user including group:users if the same user surfs to / subobject1 won't show up in the list because in the actual request object the context is the root container and not subobject1 so effective_principals returns only the principals for the user in root container and there is no group:users so has_permission against die acl of subobject1 will fail. The whole problem is the authentication policy isn't context aware. you can't pass a different context from the one in request.context to effective_principals and further down to the callback. I circumvented this problem by copying the request an changing the context before calling any authorization methods. But that's not a clean solution. There should be a way to pass the actual context to at least effective_principals because which principals are effective might depend on a different context than the one in the request. Adding a keyword argument context to effective_principals and pass it to the callback if the callback accepts one, would fix this problem without loosing backward compatibility. Regards Estartu -- --------------------------------------------------------------------------- Gerhard Schmidt | http://www.augusta.de/~estartu | Fischbachweg 3 | | PGP Public Key 86856 Hiltenfingen | JabberID: [email protected] | on request Germany | |
signature.asc
Description: OpenPGP digital signature
