Revert all work towards creating a "forbidden" API on the security policy; I'll do this work on the authchanges branch first.

1 files changed, 0 insertions, 63 deletions

diff --git a/CHANGES.txt b/CHANGES.txt
index 6df0c8171..40a810305 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,66 +1,3 @@
-Next release
-============
-
-Features
---------
-
-- It is now possible to register a custom
-  ``repoze.bfg.interfaces.IForbiddenResponseFactory`` for a given
-  application.  This feature replaces the
-  ``repoze.bfg.interfaces.IUnauthorizedAppFactory`` feature previously
-  described in the Hooks chapter.  The IForbiddenResponseFactory will
-  be called when the framework detects an authorization failure; it
-  should accept a context object and a request object; it should
-  return an IResponse object (a webob response, basically).  Read the
-  below point for more info and see the Hooks narrative chapter of the
-  BFG docs for more info; this registration trumps the security policy
-  ``forbidden`` feature when it is registered.
-
-- It is now possible to register a security policy that returns a
-  customized ``Forbidden`` response when BFG cannot authorize an
-  invocation of a view.  To this end, ISecurityPolicy objects must now
-  have a ``forbidden`` method that accepts two arguments: ``context``
-  and ``request``.  The ``context`` will be the context found by the
-  router, the ``request`` will be the current request.  This method
-  should return an IResponse (a webob response).  The returned
-  response application should be appropriate when access to a view
-  resource was forbidden by the security policy (e.g. perhaps a login
-  page or a general "forbidden" page).  ``repoze.bfg`` is willing to
-  operate with a custom security policy that does not have a
-  ``forbidden`` method, but it will issue a warning; eventually
-  security policies without a ``forbidden`` method will cease to work
-  under ``repoze.bfg``.
-
-  Note that the ``forbidden`` method of a security policy is not used
-  if a developer has registered an IForbiddenResponseFactory (see the
-  "Hooks" narrative chapter); the explicitly registered
-  IForbiddenResponseFactory will be preferred over the (more general)
-  security policy forbidden method.
-
-- All default security policies now have a ``forbidden`` callable
-  attached to them.  This particular callable returns an IResponse (a
-  webob response) with a ``401 Unauthorized`` status for backwards
-  compatibility (had backwards compatibility not been an issue, this
-  callable would have returned a WSGI app that generated a ``403
-  Forbidden`` response).
-
-Backwards Incompatibilities
----------------------------
-
-- Custom NotFound and Forbidden (nee' Unauthorized) WSGI applications
-  (registered as a utility for INotFoundAppFactory and
-  IUnauthorizedAppFactory) could rely on an environment key named
-  ``message`` describing the circumstance of the response.  This key
-  has been renamed to ``repoze.bfg.message`` (as per the WSGI spec,
-  which requires environment extensions to contain dots).
-
-Deprecations
-------------
-
-- The ``repoze.bfg.interfaces.IUnauthorizedAppFactory`` interface has
-  been deprecated in favor of using the new
-  ``repoze.bfg.interfaces.IForbiddenResponseFactory`` mechanism.
-
 0.8.1 (2009-05-21)
 ==================