On 06/20/2012 09:14 PM, Chris McDonough wrote:
I'll note that in this case, you could use a class based view as both
the factory and as the view:
from pyramid.view import view_defaults
from pyramid.view import view_config
from pyramid.security import Allow, Authenticated
@view_defaults(route_name='some_admin_thing', renderer='json',
permission='useradmin')
class UserAdmin(object):
def __init__(self, request):
self.request = request
@property
def __acl__(self):
# this is programmatic based on who is logged in,
# but the end result might be:
return [
(Allow, Authenticated, "access"),
(Allow, Authenticated, "useradmin")
]
@view_config(request_method='GET')
def GET(self):
# ...
@view_config(request_method='POST')
def POST(self):
# ...
and in the config...
config.add_route('some_admin_thing', '/admin_something',
factory=UserAdmin)
All of the views hanging off the UserAdmin object will be protected by
useradmin permission, and an instance of UserAdmin will also be used as
the context, which will put all of the security stuff in the same place,
albeit associated transitively via the 'some_admin_thing' route name.
I'll also note that the comment inside def __acl__ ("this is
programmatic based on who is logged in") is a little creepy and might
indicate that the ACL authorization policy is not being used as intended.
If you're using the ACL authorization policy, the ACL should *very
rarely* (really never) be computed based on who is logged in. An ACL is
meant to be declarative. If it can be completely static, great. Often
it needs to be computed, though. When it is computed, it should be
computed using a combination of data in your database and data in the
URL or query string of the request. In effect, URL/qs data is meant to
compose the arguments to a query which can be used to look up some data
in the database that represents a resource. The ACL protects *that
resource*.
The view execution authorization system then compares the ACL against
the principals represented by the request and the view permission and
allows or denies view execution.
ACL -> thing that protects the content; mentions permissions
and principals
principals -> currently logged in username + his groupnames
permission -> protects a view
Pyramid protects views by doing this (in this order):
- It finds the context using a factory.
- It figures out which view should be called.
- It figures out if there's a permission associated with this view.
- It computes the effective principals based on request data.
- It compares the effective principals against the ACL provided by
the context. If any of the effective principals has been granted
the permission of the view, it allows the view to execute. If
none of the effective principals has been granted the permission
of the view, or the ACL has explicitly denied any of the
effective principals the permission of the view, Pyramid prevents
the view from being executed.
In other words, it's Pyramid's job to figure out whether the current
user can execute the view based on the ACL. If the ACL is computed
based on who is logged in, things get weird pretty fast... it's just a
divide by zero error sort of, and it'd be a better idea to implement a
custom authorization policy if you want to think of things that way.
- 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.
