27.2. PROTECTING VIEWS WITH PERMISSIONS

While it is possible to mix and match different authentication and authorization policies, it is an error to configure a Pyramid application with an authentication policy but without the authorization policy or vice versa. If you do this, you’ll receive an error at application startup time.

See also the pyramid.authorization and pyramid.authentication modules for alternate implementations of authorization and authentication policies.

27.2 Protecting Views with Permissions

To protect a view callable from invocation based on a user’s security settings when a particular type of resource becomes the context, you must pass a permission to view configuration. Permissions are usually just strings, and they have no required composition: you can name permissions whatever you like.

For example, the following view declaration protects the view named add_entry.html when the context resource is of type Blog with the add permission using the pyramid.config.Configurator.add_view() API:

The equivalent view registration including the add permission name may be performed via the

@view_config decorator:

1 from pyramid.view import view_config

2 from resources import Blog

3

4 @view_config(context=Blog, name=’add_entry.html’, permission=’add’) 5 def blog_entry_add_view(request):

6""" Add blog entry code goes here """

7pass

As a result of any of these various view configuration statements, if an authorization policy is in place when the view callable is found during normal application operations, the requesting user will need to possess the add permission against the context resource in order to be able to invoke the blog_entry_add_view view. If he does not, the Forbidden view will be invoked.

295