Author ====== Shane Hathaway Zope Corporation shane at zope dot com VerboseSecurity Product ======================= Zope has a flexible, fine-grained security model that lets you configure context-dependent mappings from users to roles and from roles to permissions. The model fits most organizations' needs and has been used all over the world, but the flexibility sometimes comes at a price of complexity. One major difficulty in using the Zope security model is its lack of clarity when access is denied. Because production sites should not reveal too much about the site to those who are denied access, the lack of verbosity in the default Zope security policy is appropriate for such sites. But site developers need more details. This product attempts to explain the complete reasoning for failed access. It shows what object was being accessed, what permission is required to access it, what roles map to that permission in that context, the executable object and its owner, the effective proxy roles, and other pertinent information. All of this information appears in the exception message when access is denied. The current version of this product is designed for Zope 2.7. Installation ============ Unpack the product in your Zope Products folder. The VerboseSecurity product replaces the Zope security policy with the "VerboseSecurityPolicy". The next time an Unauthorized exception occurs, you'll get a complete explanation for the failed access. You can also see recent exceptions through the web using the error_log object. Note, however, that in the default configuration, error_log will not display Unauthorized exceptions. Just remove "Unauthorized" from the list of ignored exceptions. Side effects ============ Like all products that dynamically patch Zope, there are a few side effects: - The speed of security checks, which occur quite frequently in Zope, will be slower, especially when access is denied. The difference is unlikely to be noticeable during site development, however. - The product reveals a lot of information about the structure of your site, so it may not be appropriate for some production sites. It is unlikely to inadvertently reveal passwords, though. - The PermissionRole patch included in the product internally adds an imaginary role to the roles computed for a permission. The imaginary role is a munged version of the permission name. Consequently, it is possible to assign users to this imaginary role. This is an interesting feature to have, since it potentially lets you bypass role assignment and assign users directly to permissions. But this feature should not be regarded as standard, and it is not officially supported.