From 08ead74d05e25f58c83712f6f8651484ddc983d0 Mon Sep 17 00:00:00 2001 From: Chris McDonough Date: Tue, 26 May 2009 00:44:17 +0000 Subject: Revert all work towards creating a "forbidden" API on the security policy; I'll do this work on the authchanges branch first. --- CHANGES.txt | 63 ------------------------------------------------------------- 1 file changed, 63 deletions(-) (limited to 'CHANGES.txt') 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) ================== -- cgit v1.2.3