From e72d437280d39bf8a8f3f62c6987268537ad5b11 Mon Sep 17 00:00:00 2001 From: Tres Seaver Date: Sun, 9 Jun 2024 21:04:45 -0400 Subject: fix: store 'came_from' information in the session - As with the previous commit, we want to avoid trusting user-supplied data from the query string or form parameters when constructing redirect URLs. - Storing the route name and matchdict for the view being forbidden in the session allows us to construct the redirect URL on successful login cleanly. - In order to clarify that the logic of storing the 'came from' information is separate from rendering or processing the login form, this PR splits the `@forbidden_view` mapping onto a separate view function. --- docs/quick_tutorial/authorization.rst | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) (limited to 'docs/quick_tutorial/authorization.rst') diff --git a/docs/quick_tutorial/authorization.rst b/docs/quick_tutorial/authorization.rst index b1ef86a17..9a5b7c738 100644 --- a/docs/quick_tutorial/authorization.rst +++ b/docs/quick_tutorial/authorization.rst @@ -104,9 +104,17 @@ 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``. +screen. How does Pyramid know what is the login page to use? We defined an +explicit "forbidden view", decorating that view with +``@forbidden_view_config``, and then had it store the information about the +route being protected in the request's session, before redirecting to the +login view. + +.. note:: + + We use the session to store the ``came_from`` information, rather than a + hidden form input, in order to avoid trusting user-supplied data (from the + form or query string) when constructing redirect URLs. Extra credit -- cgit v1.2.3