On 14/06/12 15:06, Daniel Holth wrote:
> Pyramid is better at answering the question "what permission does the
> user have?", which is likely what's controlling whether they can
> actually get to the 'edit' page. Use
> pyramid.security.has_permission('edit', edit_page_context, request)
> instead.
Right, in fact if we're talking about per-instance (not per-type) ACLs
(which I've forgotten about writing my previous post) this makes perfect
sense. Still it would result in extra calls to effective_principals(),
which was my primary concern. If I display a list of objects here,
calling it for each one seems overkill without caching (if it hits the
database, that is).> After evaluating the work effective_principals actually does per-call, > if you decide you must cache effective_principals, consider > subclassing your authentication policy. The new policy could stash > them on the request but the Pyramid APIs would all work in the same way. I like the idea, as this solves both original problem as well as the one above. Any reason why Pyramid itself doesn't cache effective principals for the whole request lifespan? Well, I know that authors are not happy with overall design, as explained here http://plope.com/pyramid_auth_design_api_postmortem (and I have to say I agree with this post 100%), but principals idea is there anyway, so why not make it more efficient? > If you have one, it can also be handy to just define a request.user > property with your application-level User() object. Indeed. Thanks for the hint! BR, Przemyslaw -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
