On Fri, 2011-06-24 at 19:03 +0200, Vlad K. wrote:
> On 06/24/2011 04:51 PM, Chris McDonough wrote:
> > For better or worse, Pyramid is very explicit, and very few of its APIs
> > are optimized for less typing. I think you're suggesting that passing
> > parameters is too hard and too much typing, because you already have the
> > API you want (has_permission), it just takes more typing than you'd like
> > to use it. Am I right? Or are you missing functionality you want?
>
> No, the functionality is there. Perhaps I'm just concerned with
> performance, having to call has_permission() many times on single page
> (supplying both request and request.context to each, lazy me :) ) OR
> write my own wrapper that computes these once and then presents an easy
> to access list for checking. And since checking for individual
> permission is not an exception in a web app, I thought it could be made
> more straightforward and efficient, available out of the box.
If you mean you want to be able to do "if perm in all_perms", where
"all_perms" is some sort of list or dict provided by Pyramid (and not
just an object with a __contains__ wrapper, as I provided before), I'm
afraid it's not going to fly.
There's no Pyramid API to "get all permissions". This is on purpose.
"All permissions" can't be defined in any general enough way for it to
make sense for a Pyramid authorization policy to return a list of them.
For your use case, where there is exactly one list of permissions, and
users either have one or don't globally, I understand why you want this.
But for better or worse, Pyramid's generic security API has to take into
account the context and the potential for a pluggable authorization
policies even if you don't use one.
The list of "all permissions" for a custom authorization policy may not
be computable without undue expense, and may not even make sense to
compute. Offhand, I don't think I would know how to justify making
authorization policy writers create a "get_all_permissions" API given
the existence of "has_permission", because it would paint some
authorization policy creators into a performance and/or functionality
corner.
If you're concerned about the performance of individual calls to
has_permission, I'd just do:
has_admin = has_permission('admin', request.context, request)
has_other = has_permisssion('other', request.context, request)
Once at the top of the template/script and use the result later without
any further calls.
> But that's jumping to conclusions, though, if Pyramid is slated for
> authn/authz subsystems overhaul for 2.0.
It's not really. It's a bit more baroque than I'd like, but IMO it's
really not hurting anyone badly enough to warrant any bw incompat
change, so if the "overhaul" means any meaningful bw incompat, it's
unlikely to happen.
- C
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
