==================== Adding Authorization ==================== Our application currently allows anyone with access to the server to view, edit, and add pages to our wiki. For purposes of demonstration we'll change our application to allow people whom are members of a *group* named ``group:editors`` to add and edit wiki pages but we'll continue allowing anyone with access to the server to view pages. :app:`Pyramid` provides facilities for *authorization* and *authentication*. We'll make use of both features to provide security to our application. The source code for this tutorial stage can be browsed via `http://github.com/Pylons/pyramid/tree/master/docs/tutorials/wiki/src/authorization/ `_. Configuring a ``pyramid`` Authentication Policy -------------------------------------------------- For any :app:`Pyramid` application to perform authorization, we need to add a ``security.py`` module and we'll need to change our :term:`application registry` to add an :term:`authentication policy` and a :term:`authorization policy`. Adding Authentication and Authorization Policies ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We'll change our package's ``__init__.py`` file to enable an ``AuthTktAuthenticationPolicy`` and an ``ACLAuthorizationPolicy`` to enable declarative security checking. When you're done, your ``__init__.py`` will look like so: .. literalinclude:: src/authorization/tutorial/__init__.py :linenos: :language: python Note that the creation of an ``AuthTktAuthenticationPolicy`` requires two arguments: ``secret`` and ``callback``. ``secret`` is a string representing an encryption key used by the "authentication ticket" machinery represented by this policy: it is required. The ``callback`` is a reference to a ``groupfinder`` function in the ``tutorial`` package's ``security.py`` file. We haven't added that module yet, but we're about to. Adding ``security.py`` ~~~~~~~~~~~~~~~~~~~~~~ Add a ``security.py`` module within your package (in the same directory as ``__init__.py``, ``views.py``, etc) with the following content: .. literalinclude:: src/authorization/tutorial/security.py :linenos: :language: python The ``groupfinder`` function defined here is an authorization policy "callback"; it is a callable that accepts a userid and a request. If the userid exists in the set of users known by the system, the callback will return a sequence of group identifiers (or an empty sequence if the user isn't a member of any groups). If the userid *does not* exist in the system, the callback will return ``None``. In a production system this data will most often come from a database, but here we use "dummy" data to represent user and groups sources. Note that the ``editor`` user is a member of the ``group:editors`` group in our dummy group data (the ``GROUPS`` data structure). Adding Login and Logout Views ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We'll add a ``login`` view which renders a login form and processes the post from the login form, checking credentials. We'll also add a ``logout`` view to our application and provide a link to it. This view will clear the credentials of the logged in user and redirect back to the front page. We'll add a different file (for presentation convenience) to add login and logout views. Add a file named ``login.py`` to your application (in the same directory as ``views.py``) with the following content: .. literalinclude:: src/authorization/tutorial/login.py :linenos: :language: python Note that the ``login`` view callable in the ``login.py`` file has *two* view configuration decorators. The order of these decorators is unimportant. Each just adds a different :term:`view configuration` for the ``login`` view callable. The first view configuration decorator configures the ``login`` view callable so it will be invoked when someone visits ``/login`` (when the context is a Wiki and the view name is ``login``). The second decorator (with context of ``pyramid.exceptions.Forbidden``) specifies a :term:`forbidden view`. This configures our login view to be presented to the user when :app:`Pyramid` detects that a view invocation can not be authorized. Because we've configured a forbidden view, the ``login`` view callable will be invoked whenever one of our users tries to execute a view callable that they are not allowed to invoke as determined by the :term:`authorization policy` in use. In our application, for example, this means that if a user has not logged in, and he tries to add or edit a Wiki page, he will be shown the login form. Before being allowed to continue on to the add or edit form, he will have to provide credentials that give him permission to add or edit via this login form. Changing Existing Views ~~~~~~~~~~~~~~~~~~~~~~~ Then we need to change each of our ``view_page``, ``edit_page`` and ``add_page`` views in ``views.py`` to pass a "logged in" parameter into its template. We'll add something like this to each view body: .. ignore-next-block .. code-block:: python :linenos: from pyramid.security import authenticated_userid logged_in = authenticated_userid(request) We'll then change the return value of each view that has an associated ``renderer`` to pass the `resulting `logged_in`` value to the template. For example: .. ignore-next-block .. code-block:: python :linenos: return dict(page = context, content = content, logged_in = logged_in, edit_url = edit_url) Adding the ``login.pt`` Template ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Add a ``login.pt`` template to your templates directory. It's referred to within the login view we just added to ``login.py``. .. literalinclude:: src/authorization/tutorial/templates/login.pt :language: xml :tab-width: 2 Change ``view.pt`` and ``edit.pt`` ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We'll also need to change our ``edit.pt`` and ``view.pt`` templates to display a "Logout" link if someone is logged in. This link will invoke the logout view. To do so we'll add this to both templates within the ``