From bd8f73be18f8f54daff34debd976a4b81be886aa Mon Sep 17 00:00:00 2001 From: Michael Merickel Date: Sun, 29 Dec 2019 23:29:48 -0600 Subject: update authentication and authorization chapters of the quick_tutorial to use the new ISecurityPolicy --- docs/quick_tutorial/authentication.rst | 30 +++++++++++++----------------- 1 file changed, 13 insertions(+), 17 deletions(-) (limited to 'docs/quick_tutorial/authentication.rst') diff --git a/docs/quick_tutorial/authentication.rst b/docs/quick_tutorial/authentication.rst index cd038ea36..12eb738e2 100644 --- a/docs/quick_tutorial/authentication.rst +++ b/docs/quick_tutorial/authentication.rst @@ -55,16 +55,15 @@ Steps :language: ini :linenos: -#. Get authentication (and for now, authorization policies) and login route - into the :term:`configurator` in ``authentication/tutorial/__init__.py``: +#. Create an ``authentication/tutorial/security.py`` module that can find our + user information by providing a :term:`security policy`: - .. literalinclude:: authentication/tutorial/__init__.py + .. literalinclude:: authentication/tutorial/security.py :linenos: -#. Create an ``authentication/tutorial/security.py`` module that can find our - user information by providing an *authentication policy callback*: +#. Register the ``SecurityPolicy`` with the :term:`configurator` in ``authentication/tutorial/__init__.py``: - .. literalinclude:: authentication/tutorial/security.py + .. literalinclude:: authentication/tutorial/__init__.py :linenos: #. Update the views in ``authentication/tutorial/views.py``: @@ -111,14 +110,12 @@ are you) and authorization (what are you allowed to do) are not just pluggable, but decoupled. To learn one step at a time, we provide a system that identifies users and lets them log out. -In this example we chose to use the bundled :ref:`AuthTktAuthenticationPolicy -` policy. We enabled it in our configuration and -provided a ticket-signing secret in our INI file. +In this example we chose to use the bundled :class:`pyramid.authentication.AuthTktCookieHelper` helper to store the user's logged-in state in a cookie. +We enabled it in our configuration and provided a ticket-signing secret in our INI file. Our view class grew a login view. When you reached it via a ``GET`` request, it returned a login form. When reached via ``POST``, it processed the submitted -username and password against the "groupfinder" callable that we registered in -the configuration. +username and password against the ``USERS`` data store. The function ``hash_password`` uses a one-way hashing algorithm with a salt on the user's password via ``bcrypt``, instead of storing the password in plain @@ -134,6 +131,9 @@ submitted password and the user's password stored in the database. If the hashed values are equivalent, then the user is authenticated, else authentication fails. +Assuming the password was validated, we invoke :func:`pyramid.security.remember` to generate a cookie that is set in the response. +Subsequent requests return that cookie and identify the user. + In our template, we fetched the ``logged_in`` value from the view class. We use this to calculate the logged-in user, if any. In the template we can then choose to show a login link to anonymous visitors or a logout link to logged-in @@ -143,13 +143,9 @@ users. Extra credit ============ -#. What is the difference between a user and a principal? - -#. Can I use a database behind my ``groupfinder`` to look up principals? +#. Can I use a database instead of ``USERS`` to authenticate users? #. Once I am logged in, does any user-centric information get jammed onto each request? Use ``import pdb; pdb.set_trace()`` to answer this. -.. seealso:: See also :ref:`security_chapter`, - :ref:`AuthTktAuthenticationPolicy `, `bcrypt - `_ +.. seealso:: See also :ref:`security_chapter`, :class:`pyramid.authentication.AuthTktCookieHelper`, `bcrypt `_ -- cgit v1.2.3