| Age | Commit message (Collapse) | Author |
|---|
|
|
|
--------
- Two new security policies were added:
RemoteUserInheritingACLSecurityPolicy and
WhoInheritingACLSecurityPolicy. These are security policies which
take into account *all* ACLs defined in the lineage of a context
rather than stopping at the first ACL found in a lineage. See the
"Security" chapter of the API documentation for more information.
- The API and narrative documentation dealing with security was
changed to introduce the new "inheriting" security policy variants.
- Added glossary entry for "lineage".
Deprecations
------------
- The security policy previously named
``RepozeWhoIdentityACLSecurityPolicy`` now has the slightly saner
name of ``WhoACLSecurityPolicy``. A deprecation warning is emitted
when this policy is imported under the "old" name; usually this is
due to its use in ZCML within your application. If you're getting
this deprecation warning, change your ZCML to use the new name,
e.g. change::
<utility
provides="repoze.bfg.interfaces.ISecurityPolicy"
factory="repoze.bfg.security.RepozeWhoIdentityACLSecurityPolicy"
/>
To::
<utility
provides="repoze.bfg.interfaces.ISecurityPolicy"
factory="repoze.bfg.security.WhoACLSecurityPolicy"
/>
|
|
and cleanUp functions in repoze.bfg.testing. Our dependencies still rely on zope.testing, however.
|
|
|
|
list of permissions (e.g. ``(Allow, Everyone, ['read', ['view',
['write', 'manage']]])`)`. The list must instead be fully expanded
(e.g. ``(Allow, Everyone, ['read', 'view', 'write', 'manage])``). This
feature was never documented, and was never an API, so it's not a
backwards incompatibility.
|
|
|
|
``ACLSecurityPolicy`` now does what it did inline.
- Get rid of ``repoze.bfg.interfaces.NoAuthorizationInformation``
exception: it was used only by ``ACLAuthorizer``.
|
|
``repoze.bfg.ACLAuthorizer.permits`` (e.g. ['fred', ['larry',
'bob']). The principals list must be fully expanded. This feature
was never documented, and was never an API, so it's not a backwards
incompatibility.
|
|
|
|
|
|
- Remove old cold which attempts to recover from trying to unpickle a
``z3c.pt`` template; Chameleon has been the templating engine for a
good long time now. Running repoze.bfg against a sandbox that has
pickled ``z3c.pt`` templates it will now just fail with an
unpickling error, but can be fixed by deleting the template cache
files.
|
|
TypeError (use ``ACLDenied`` instead of ``Denied``).
|
|
- The ``BFG_DEBUG_AUTHORIZATION`` envvar and the
``debug_authorization`` config file value now only imply debugging
of view-invoked security checks. Previously, information was
printed for every call to ``has_permission`` as well, which made
output confusing. To debug ``has_permission`` checks and other
manual permission checks, use the debugger and print statements in
your own code.
- Authorization debugging info is now only present in the HTTP
response body oif ``debug_authorization`` is true.
- The format of authorization debug messages was improved.
- A new ``BFG_DEBUG_NOTFOUND`` envvar was added and a symmetric
``debug_notfound`` config file value was added. When either is
true, and a NotFound response is returned by the BFG router
(because a view could not be found), debugging information is
printed to stderr. When this value is set true, the body of
HTTPNotFound responses will also contain the same debugging
information.
- ``Allowed`` and ``Denied`` responses from the security machinery
are now specialized into two types: ACL types, and non-ACL types.
The ACL-related responses are instances of
``repoze.bfg.security.ACLAllowed`` and
``repoze.bfg.security.ACLDenied``. The non-ACL-related responses
are ``repoze.bfg.security.Allowed`` and
``repoze.bfg.security.Denied``. The allowed-type responses
continue to evaluate equal to things that themselves evaluate
equal to the ``True`` boolean, while the denied-type responses
continue to evaluate equal to things that themselves evaluate
equal to the ``False`` boolean. The only difference between the
two types is the information attached to them for debugging
purposes.
- Added a new ``BFG_DEBUG_ALL`` envvar and a symmetric ``debug_all``
config file value. When either is true, all other debug-related
flags are set true unconditionally (e.g. ``debug_notfound`` and
``debug_authorization``).
Documentation
- Added info about debug flag changes.
- Added a section to the security chapter named "Debugging
Imperative Authorization Failures" (for e.g. ``has_permssion``).
|
|
this logger is registered unconditionally and is used by the
authorization debug machinery. Applications may also make use of
it as necessary rather than inventing their own logger, for
convenience.
|
|
- An "Environment and Configuration" chapter was added to the narrative
portion of the documentation.
Features
- Ensure bfg doesn't generate warnings when running under Python
2.6.
- The environment variable ``BFG_RELOAD_TEMPLATES`` is now available
(serves the same purpose as ``reload_templates`` in the config file).
- A new configuration file option ``debug_authorization`` was added.
This turns on printing of security authorization debug statements
to ``sys.stderr``. The ``BFG_DEBUG_AUTHORIZATION`` environment
variable was also added; this performs the same duty.
Bug Fixes
- The environment variable ``BFG_SECURITY_DEBUG`` did not always work.
It has been renamed to ``BFG_DEBUG_AUTHORIZATION`` and fixed.
Deprecations
- A deprecation warning is now issued when old API names from the
``repoze.bfg.templates`` module are imported.
Backwards incompatibilities
- The ``BFG_SECURITY_DEBUG`` environment variable was renamed to
``BFG_DEBUG_AUTHORIZATION``.
|
|
|
|
|
|
|
|
policy.
|
|
|
|
|
|
|
|
|
