Skip to content
Fetching contributors…
Cannot retrieve contributors at this time
118 lines (72 sloc) 3.46 KB

21: Protecting Resources With Authorization

Assign security statements to resources describing the permissions required to perform an operation.


Our application has URLs that allow people to add/edit/delete content via a web browser. Time to add security to the application. Let's protect our add/edit views to require a login (username of editor and password of editor). We will allow the other views to continue working without a password.


  • Introduce the Pyramid concepts of authentication, authorization, permissions, and access control lists (ACLs).
  • Make a :term:`root factory` that returns an instance of our class for the top of the application.
  • Assign security statements to our root resource.
  • Add a permissions predicate on a view.
  • Provide a :term:`Forbidden view` to handle visiting a URL without adequate permissions.


  1. We are going to use the authentication step as our starting point:

    $ cd ..; cp -r authentication authorization; cd authorization
    $ $VENV/bin/pip install -e .
  2. Start by changing authorization/tutorial/ to specify a root factory to the :term:`configurator`:

  3. That means we need to implement authorization/tutorial/

  4. Change authorization/tutorial/ to require the edit permission on the hello view and implement the forbidden view:

  5. Run your Pyramid application with:

    $ $VENV/bin/pserve development.ini --reload
  6. Open http://localhost:6543/ in a browser.

  7. If you are still logged in, click the "Log Out" link.

  8. Visit http://localhost:6543/howdy in a browser. You should be asked to login.


This simple tutorial step can be boiled down to the following:

  • A view can require a permission (edit).
  • The context for our view (the Root) has an access control list (ACL).
  • This ACL says that the edit permission is available on Root to the group:editors principal.
  • The registered groupfinder answers whether a particular user (editor) has a particular group (group:editors).

In summary, hello wants edit permission, Root says group:editors has edit permission.

Of course, this only applies on Root. Some other part of the site (a.k.a. context) might have a different ACL.

If you are not logged in and visit /howdy, you need to get shown the login screen. How does Pyramid know what is the login page to use? We explicitly told Pyramid that the login view should be used by decorating the view with @forbidden_view_config.

Extra credit

  1. Do I have to put a renderer in my @forbidden_view_config decorator?
  2. Perhaps you would like the experience of not having enough permissions (forbidden) to be richer. How could you change this?
  3. Perhaps we want to store security statements in a database and allow editing via a browser. How might this be done?
  4. What if we want different security statements on different kinds of objects? Or on the same kinds of objects, but in different parts of a URL hierarchy?
Something went wrong with that request. Please try again.