On 06/14/2012 09:55 AM, Przemyslaw Wegrzyn wrote:
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?
Becase, eventually, someone will need to clear the cache when the list
of effective principals changes as the result of something happening
during a request, such as the current user obtaining a new group or
losing a group. Since the way principals are computed is
application-specific, the framework itself can't know when this happens,
and so it can't clear any cache automatically. And rather than
violating rule of least surprise wrt the freshness of the list of
effective principals and a framework-level cache, we leave it up to the
application to do the caching and clearing of that cache.
But as noted by that post, the groupfinder abstraction is dumb. People
should just create a new authentication policy or subclass an existing
policy. When you do this, there's a natural place to add caching.
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!
One way to do this is documented here:
http://docs.pylonsproject.org/projects/pyramid_cookbook/en/latest/auth/user_object.html
This example does indeed cause the user object itself to be cached for
the duration of the request (although its attributes, such as groups,
won't be cached, of course).
- C
--
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.
