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.

1 files changed, 11 insertions, 3 deletions

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