27. SECURITY
27.2.1 Setting a Default Permission
If a permission is not supplied to a view configuration, the registered view will always be executable by entirely anonymous users: any authorization policy in effect is ignored.
In support of making it easier to configure applications which are “secure by default”, Pyramid allows you to configure a default permission. If supplied, the default permission is used as the permission string to all view registrations which don’t otherwise name a permission argument.
The pyramid.config.Configurator.set_default_permission() method supports configuring a default permission for an application.
When a default permission is registered:
•If a view configuration names an explicit permission, the default permission is ignored for that view registration, and the view-configuration-named permission is used.
•If a view configuration names the permission pyramid.security.NO_PERMISSION_REQUIRED, the default permission is ignored, and the view is registered without a permission (making it available to all callers regardless of their credentials).
|
|
|
|
|
|
|
|
|
latex-warning.png |
|
|
|
|
|
|
|
|
When you register a default permission, |
all views |
(even |
exception |
||
view views) are protected by a permission. |
For all |
views |
which are |
truly |
meant to |
||
be anonymously accessible, you will need to associate |
the view’s configuration with the |
||||||
pyramid.security.NO_PERMISSION_REQUIRED permission. |
|
|
|
||||
|
|
|
|
|
|
|
|
27.3 Assigning ACLs to your Resource Objects
When the default Pyramid authorization policy determines whether a user possesses a particular permission with respect to a resource, it examines the ACL associated with the resource. An ACL is associated with a resource by adding an __acl__ attribute to the resource object. This attribute can be defined on the resource instance if you need instance-level security, or it can be defined on the resource class if you just need type-level security.
For example, an ACL might be attached to the resource for a blog via its class:
296
27.4. ELEMENTS OF AN ACL
1 from pyramid.security import Everyone
2 from pyramid.security import Allow
3
4 class Blog(object):
5__acl__ = [
6(Allow, Everyone, ’view’),
7(Allow, ’group:editors’, ’add’),
8(Allow, ’group:editors’, ’edit’),
9]
Or, if your resources are persistent, an ACL might be specified via the __acl__ attribute of an instance of a resource:
1 from pyramid.security import Everyone
2 from pyramid.security import Allow
3
4 class Blog(object):
5pass
6
7 blog = Blog()
8
9 blog.__acl__ = [
10(Allow, Everyone, ’view’),
11(Allow, ’group:editors’, ’add’),
12(Allow, ’group:editors’, ’edit’),
13]
Whether an ACL is attached to a resource’s class or an instance of the resource itself, the effect is the same. It is useful to decorate individual resource instances with an ACL (as opposed to just decorating their class) in applications such as “CMS” systems where fine-grained access is required on an object-by- object basis.
27.4 Elements of an ACL
Here’s an example ACL:
1
2
3
4
from pyramid.security import Everyone from pyramid.security import Allow
__acl__ = [
297
27. SECURITY
5
6
7
8
(Allow, Everyone, ’view’), (Allow, ’group:editors’, ’add’), (Allow, ’group:editors’, ’edit’),
]
The example ACL indicates that the pyramid.security.Everyone principal – a special systemdefined principal indicating, literally, everyone – is allowed to view the blog, the group:editors principal is allowed to add to and edit the blog.
Each element of an ACL is an ACE or access control entry. For example, in the above code block, there are three ACEs: (Allow, Everyone, ’view’), (Allow, ’group:editors’, ’add’), and (Allow, ’group:editors’, ’edit’).
The first element of any ACE is either pyramid.security.Allow, or pyramid.security.Deny, representing the action to take when the ACE matches. The second element is a principal. The third argument is a permission or sequence of permission names.
A principal is usually a user id, however it also may be a group id if your authentication system provides group information and the effective authentication policy policy is written to respect group information. For example, the pyramid.authentication.RepozeWho1AuthenicationPolicy respects group information if you configure it with a callback.
Each ACE in an ACL is processed by an authorization policy in the order dictated by the ACL. So if you have an ACL like this:
1
2
3
4
5
6
7
8
from pyramid.security import Everyone from pyramid.security import Allow from pyramid.security import Deny
__acl__ = [
(Allow, Everyone, ’view’), (Deny, Everyone, ’view’),
]
The default authorization policy will allow everyone the view permission, even though later in the ACL you have an ACE that denies everyone the view permission. On the other hand, if you have an ACL like this:
1
2
3
from pyramid.security import Everyone from pyramid.security import Allow from pyramid.security import Deny
4
298
27.5. SPECIAL PRINCIPAL NAMES
5
6
7
8
__acl__ = [
(Deny, Everyone, ’view’), (Allow, Everyone, ’view’),
]
The authorization policy will deny everyone the view permission, even though later in the ACL is an ACE that allows everyone.
The third argument in an ACE can also be a sequence of permission names instead of a single permission name. So instead of creating multiple ACEs representing a number of different permission grants to a single group:editors group, we can collapse this into a single ACE, as below.
1 from pyramid.security import Everyone
2 from pyramid.security import Allow
3
4 __acl__ = [
5(Allow, Everyone, ’view’),
6(Allow, ’group:editors’, (’add’, ’edit’)),
7]
27.5 Special Principal Names
Special principal names exist in the pyramid.security module. They can be imported for use in your own code to populate ACLs, e.g. pyramid.security.Everyone.
pyramid.security.Everyone
Literally, everyone, no matter what. This object is actually a string “under the hood” (system.Everyone). Every user “is” the principal named Everyone during every request, even if a security policy is not in use.
pyramid.security.Authenticated
Any user with credentials as determined by the current security policy. You might think of it as any user that is “logged in”. This object is actually a string “under the hood” (system.Authenticated).
299