Файл: pyramid.pdf

26. TRAVERSAL

The Example View Callables Accept Only a Request; How Do I Access the Context Resource?

Most of the examples in this book assume that a view callable is typically passed only a request object. Sometimes your view callables need access to the context resource, especially when you use traversal. You might use a supported alternate view callable argument list in your view callables such as the (context, request) calling convention described in Alternate View Callable Argument/Calling Conventions. But you don’t need to if you don’t want to. In view callables that accept only a request, the context resource found by traversal is available as the context attribute of the request object, e.g. request.context. The view name is available as the view_name attribute of the request object, e.g. request.view_name. Other Pyramid -specific request attributes are also available as described in Special Attributes Added to the Request by Pyramid.

26.3.3 Using Resource Interfaces In View Configuration

Instead of registering your views with a context that names a Python resource class, you can optionally register a view callable with a context which is an interface. An interface can be attached arbitrarily to any resource object. View lookup treats context interfaces specially, and therefore the identity of a resource can be divorced from that of the class which implements it. As a result, associating a view with an interface can provide more flexibility for sharing a single view between two or more different implementations of a resource type. For example, if two resource objects of different Python class types share the same interface, you can use the same view configuration to specify both of them as a context.

In order to make use of interfaces in your application during view dispatch, you must create an interface and mark up your resource classes or instances with interface declarations that refer to this interface.

To attach an interface to a resource class, you define the interface and use the zope.interface.implementer() class decorator to associate the interface with the class.

3

4 class IHello(Interface):

5""" A marker interface """

6

7 @implementer(IHello)

8 class Hello(object):

9pass

To attach an interface to a resource instance, you define the interface and use the zope.interface.alsoProvides() function to associate the interface with the instance. This function mutates the instance in such a way that the interface is attached to it.

290

26.3. THE TRAVERSAL ALGORITHM

3

4 class IHello(Interface):

5""" A marker interface """

6

7 class Hello(object):

8pass

9

10def make_hello():

11hello = Hello()

12alsoProvides(hello, IHello)

13return hello

Regardless of how you associate an interface, with a resource instance, or a resource class, the resulting code to associate that interface with a view callable is the same. Assuming the above code that defines an IHello interface lives in the root of your application, and its module is named “resources.py”, the interface declaration below will associate the mypackage.views.hello_world view with resources that implement, or provide, this interface.

Any time a resource that is determined to be the context provides this interface, and a view named hello.html is looked up against it as per the URL, the mypackage.views.hello_world view callable will be invoked.

Note, in cases where a view is registered against a resource class, and a view is also registered against an interface that the resource class implements, an ambiguity arises. Views registered for the resource class take precedence over any views registered for any interface the resource class implements. Thus, if one view configuration names a context of both the class type of a resource, and another view configuration names a context of interface implemented by the resource’s class, and both view configurations are otherwise identical, the view registered for the context’s class will “win”.

For more information about defining resources with interfaces for use within view configuration, see

Resources Which Implement Interfaces.

291

26. TRAVERSAL

26.4 References

A tutorial showing how traversal can be used within a Pyramid application exists in ZODB + Traversal Wiki Tutorial.

See the View Configuration chapter for detailed information about view lookup.

The pyramid.traversal module contains API functions that deal with traversal, such as traversal invocation from within application code.

The pyramid.request.Request.resource_url() method generates a URL when given a resource retrieved from a resource tree.

292

CHAPTER

TWENTYSEVEN

SECURITY

Pyramid provides an optional declarative authorization system that can prevent a view from being invoked based on an authorization policy. Before a view is invoked, the authorization system can use the credentials in the request along with the context resource to determine if access will be allowed. Here’s how it works at a high level:

•A request is generated when a user visits the application.

•Based on the request, a context resource is located through resource location. A context is located differently depending on whether the application uses traversal or URL dispatch, but a context is ultimately found in either case. See the URL Dispatch chapter for more information.

•A view callable is located by view lookup using the context as well as other attributes of the request.

•If an authentication policy is in effect, it is passed the request; it returns some number of principal identifiers.

•If an authorization policy is in effect and the view configuration associated with the view callable that was found has a permission associated with it, the authorization policy is passed the context, some number of principal identifiers returned by the authentication policy, and the permission associated with the view; it will allow or deny access.

•If the authorization policy allows access, the view callable is invoked.

•If the authorization policy denies access, the view callable is not invoked; instead the forbidden view is invoked.

Security in Pyramid, unlike many systems, cleanly and explicitly separates authentication and authorization. Authentication is merely the mechanism by which credentials provided in the request are resolved to one or more principal identifiers. These identifiers represent the users and groups in effect during the request. Authorization then determines access based on the principal identifiers, the view callable being invoked, and the context resource.

Authorization is enabled by modifying your application to include an authentication policy and authorization policy. Pyramid comes with a variety of implementations of these policies. To provide maximal flexibility, Pyramid also allows you to create custom authentication policies and authorization policies.

293

27. SECURITY

27.1 Enabling an Authorization Policy

By default, Pyramid enables no authorization policy. All views are accessible by completely anonymous users. In order to begin protecting views from execution based on security settings, you need to enable an authorization policy.

27.1.1 Enabling an Authorization Policy Imperatively

Use the set_authorization_policy() method of the Configurator to enable an authorization policy.

You must also enable an authentication policy in order to enable the authorization policy. This is because authorization, in general, depends upon authentication. Use the set_authentication_policy() and method during application setup to specify the authentication policy.

For example:

latex-note.png

the authentication_policy and authorization_policy arguments may also be passed to their respective methods mentioned above as dotted Python name values, each representing the dotted name path to a suitable implementation global defined at Python module scope.

The above configuration enables a policy which compares the value of an “auth ticket” cookie passed in the request’s environment which contains a reference to a single principal against the principals present in any ACL found in the resource tree when attempting to call some view.

294