Not logged in - Log In / Register

Launchpad Security Policy

Launchpad uses "permission" to control access to views, object attributes and object methods.

Permission are granted based on the context object type (its interface) by an IAuthorization adapters. Traditionnally these adapters have all been defined in the module, but they are being moved out in the module of the specific application.

To find out who has a named permission on an object, the IAuthorization adapter named after the permission is looked for. Simply put, to see if the "launchpad.Permission" is granted on an IFoo object, the answer will come from the object returned by

Common permissions

Launchpad defines two permissions that are always defined for all objects with a hard-coded set of users.

Then there is a set of basic permissions that have a common semantic, but which the users granted it will differ based on the object type.

These permissions are also layered, in the sense that having an higher permission usually implies the one below. (For example, launchpad.Admin implies Edit, Append, View, etc.) The only exception to this rule is for launchpad.Moderate which implies View, but not necessarily Edit nor Append.

Launchpad defines and use a couple of special permissions that are less generic and don't fit in this layered model. We should refrain from adding these as they make understanding the model more complex.

Assigning permissions

zcml directives assign permissions to the attributes of interface implementations. This means that a user may have permission to access an attribute, without actually being able to.


The SecurityProxy is a wrapper that enforces these requirements. It does not apply to classes that are constructed directly. If no permission is assigned to a given attribute, attempting to access it is forbidden. If there is a permission assigned to it, and the current user does not have that permission, attempting it is unauthorized. If the current user has the correct permission, then that attribute will behave almost exactly the same as it would on an un-proxied object. The main difference is that any return values may be wrapped in a SecurityProxy as well.


There are several possible causes:

This is not the same as Unauthorized. Unauthorized means that an authorization regime has been properly set up, but the current user is not authorized.

LaunchpadSecurityPolicy (last edited 2009-07-15 20:11:54 by flacoste)