- When a ``pyramid.exceptions.Forbidden`` error is raised, its status code

  now ``403 Forbidden``.  It was previously ``401 Unauthorized``, for
  backwards compatibility purposes with ``repoze.bfg``.  This change will
  cause problems for users of Pyramid with ``repoze.who``, which intercepts
  ``401 Unauthorized`` by default, but allows ``403 Forbidden`` to pass
  through.  Those deployments will need to configure ``repoze.who`` to also
  react to ``403 Forbidden``.

1 files changed, 1 insertions, 7 deletions

diff --git a/docs/narr/hooks.rst b/docs/narr/hooks.rst
index 6b1522846..b3b41046f 100644
--- a/docs/narr/hooks.rst
+++ b/docs/narr/hooks.rst
@@ -80,7 +80,7 @@ Changing the Forbidden View
 
 When :app:`Pyramid` can't authorize execution of a view based on the
 :term:`authorization policy` in use, it invokes a :term:`forbidden view`.
-The default forbidden response has a 401 status code and is very plain, but
+The default forbidden response has a 403 status code and is very plain, but
 the view which generates it can be overridden as necessary.
 
 The :term:`forbidden view` callable is a view callable like any other.  The
@@ -129,12 +129,6 @@ Here's some sample code that implements a minimal forbidden view:
    ``debug_authorization`` environment setting is true than it is when
    it is false.
 
-.. warning:: the default forbidden view sends a response with a ``401
-   Unauthorized`` status code for backwards compatibility reasons.
-   You can influence the status code of Forbidden responses by using
-   an alternate forbidden view.  For example, it would make sense to
-   return a response with a ``403 Forbidden`` status code.
-
 .. index::
    single: request factory