Am 02.06.2014 09:20, schrieb Laurence Rowe: > On Wednesday, 28 May 2014 00:17:11 UTC-7, Gerhard Schmidt wrote: > > 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. > > > It sounds like you are trying to replicate role based access control > through context sensitive groups. Rather than implement this in the > context insensitive groupfinder callback, you should implement it on the > authorization policy level.
Authorization policy gets the principals returned by the group finder which may include the original principal but may not. So i would have to re implement the group finder within the authorization policy. Sounds redundant to me. The group finder would effectively called with it's results repeatedly. Which might get quite a performance break if the first iteration return quite a view principals. Making the authentication policy context aware doesn't have this redundancy and therefor a much lesser performance impact. (None if the context is not used) 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
