Navigation

Our application currently allows anyone with access to the server to view,
edit, and add pages to our wiki. For purposes of demonstration we’ll change
our application to allow people whom are members of a group named
group:editors to add and edit wiki pages but we’ll continue allowing
anyone with access to the server to view pages. Pyramid provides
facilities for authorization and authentication. We’ll make
use of both features to provide security to our application.

Note that the creation of an AuthTktAuthenticationPolicy requires two
arguments: secret and callback. secret is a string representing
an encryption key used by the “authentication ticket” machinery represented
by this policy: it is required. The callback is a reference to a
groupfinder function in the tutorial package’s security.py file.
We haven’t added that module yet, but we’re about to.

fromrepoze.zodbconn.finderimportPersistentApplicationFinderfrompyramid.configimportConfiguratorfrompyramid.authenticationimportAuthTktAuthenticationPolicyfrompyramid.authorizationimportACLAuthorizationPolicyfromtutorial.modelsimportappmakerfromtutorial.securityimportgroupfinderdefmain(global_config,**settings):""" This function returns a WSGI application. It is usually called by the PasteDeploy framework during ``paster serve``. """authn_policy=AuthTktAuthenticationPolicy(secret='sosecret',callback=groupfinder)authz_policy=ACLAuthorizationPolicy()zodb_uri=settings.get('zodb_uri',False)ifzodb_uriisFalse:raiseValueError("No 'zodb_uri' in application configuration.")finder=PersistentApplicationFinder(zodb_uri,appmaker)defget_root(request):returnfinder(request.environ)config=Configurator(root_factory=get_root,settings=settings,authentication_policy=authn_policy,authorization_policy=authz_policy)config.add_static_view('static','tutorial:static')config.scan('tutorial')returnconfig.make_wsgi_app()

The groupfinder function defined here is an authentication policy
“callback”; it is a callable that accepts a userid and a request. If the
userid exists in the system, the callback will
return a sequence of group identifiers (or an empty sequence if the user
isn’t a member of any groups). If the userid does not exist in the system,
the callback will return None. In a production system, user and group data will
most often come from a database, but here we use “dummy” data to represent
user and groups sources. Note that the editor user is a member of the
group:editors group in our dummy group data (the GROUPS data
structure).

We need to give our root resource object an ACL. This ACL will be
sufficient to provide enough information to the Pyramid security
machinery to challenge a user who doesn’t have appropriate credentials when
he attempts to invoke the add_page or edit_page views.

We need to perform some imports at module scope in our models.py file:

1
2

frompyramid.securityimportAllowfrompyramid.securityimportEveryone

Our root resource object is a Wiki instance. We’ll add the following
line at class scope to our Wiki class:

1
2

__acl__=[(Allow,Everyone,'view'),(Allow,'group:editors','edit')]

It’s only happenstance that we’re assigning this ACL at class scope. An ACL
can be attached to an object instance too; this is how “row level security”
can be achieved in Pyramid applications. We actually only need one
ACL for the entire system, however, because our security requirements are
simple, so this feature is not demonstrated.

frompersistentimportPersistentfrompersistent.mappingimportPersistentMappingfrompyramid.securityimportAllowfrompyramid.securityimportEveryoneclassWiki(PersistentMapping):__name__=None__parent__=None__acl__=[(Allow,Everyone,'view'),(Allow,'group:editors','edit')]classPage(Persistent):def__init__(self,data):self.data=datadefappmaker(zodb_root):ifnot'app_root'inzodb_root:app_root=Wiki()frontpage=Page('This is the front page')app_root['FrontPage']=frontpagefrontpage.__name__='FrontPage'frontpage.__parent__=app_rootzodb_root['app_root']=app_rootimporttransactiontransaction.commit()returnzodb_root['app_root']

frompyramid.httpexceptionsimportHTTPFoundfrompyramid.securityimportrememberfrompyramid.securityimportforgetfrompyramid.viewimportview_configfrompyramid.urlimportresource_urlfromtutorial.securityimportUSERS@view_config(context='tutorial.models.Wiki',name='login',renderer='templates/login.pt')@view_config(context='pyramid.httpexceptions.HTTPForbidden',renderer='templates/login.pt')deflogin(request):login_url=resource_url(request.context,request,'login')referrer=request.urlifreferrer==login_url:referrer='/'# never use the login form itself as came_fromcame_from=request.params.get('came_from',referrer)message=''login=''password=''if'form.submitted'inrequest.params:login=request.params['login']password=request.params['password']ifUSERS.get(login)==password:headers=remember(request,login)returnHTTPFound(location=came_from,headers=headers)message='Failed login'returndict(message=message,url=request.application_url+'/login',came_from=came_from,login=login,password=password,)@view_config(context='tutorial.models.Wiki',name='logout')deflogout(request):headers=forget(request)returnHTTPFound(location=resource_url(request.context,request),headers=headers)

Note that the login view callable in the login.py file has two view
configuration decorators. The order of these decorators is unimportant.
Each just adds a different view configuration for the login view
callable.

The first view configuration decorator configures the login view callable
so it will be invoked when someone visits /login (when the context is a
Wiki and the view name is login). The second decorator (with context of
pyramid.httpexceptions.HTTPForbidden) specifies a forbidden view.
This configures our login view to be presented to the user when
Pyramid detects that a view invocation can not be authorized. Because
we’ve configured a forbidden view, the login view callable will be
invoked whenever one of our users tries to execute a view callable that they
are not allowed to invoke as determined by the authorization policy
in use. In our application, for example, this means that if a user has not
logged in, and he tries to add or edit a Wiki page, he will be shown the
login form. Before being allowed to continue on to the add or edit form, he
will have to provide credentials that give him permission to add or edit via
this login form.

To protect each of our views with a particular permission, we need to pass a
permission argument to each of our pyramid.view.view_config
decorators. To do so, within views.py:

We add permission='view' to the decorator attached to the
view_wiki and view_page view functions. This makes the
assertion that only users who possess the view permission
against the context resource at the time of the request may
invoke these views. We’ve granted
pyramid.security.Everyone the view permission at the
root model via its ACL, so everyone will be able to invoke the
view_wiki and view_page views.

We add permission='edit' to the decorator attached to the
add_page and edit_page view functions. This makes the
assertion that only users who possess the effective edit
permission against the context resource at the time of the
request may invoke these views. We’ve granted the
group:editors principal the edit permission at the
root model via its ACL, so only a user whom is a member of
the group named group:editors will able to invoke the
add_page or edit_page views. We’ve likewise given
the editor user membership to this group via the
security.py file by mapping him to the group:editors
group in the GROUPS data structure (GROUPS={'editor':['group:editors']}); the groupfinder
function consults the GROUPS data structure. This means
that the editor user can add and edit pages.

We can finally examine our application in a browser. The views we’ll try are
as follows:

Visiting http://localhost:6543/ in a browser invokes the view_wiki
view. This always redirects to the view_page view of the FrontPage
page resource. It is executable by any user.

Visiting http://localhost:6543/FrontPage/ in a browser invokes the
view_page view of the FrontPage Page resource. This is because
it’s the default view (a view without a name) for Page
resources. It is executable by any user.

Visiting http://localhost:6543/FrontPage/edit_page in a browser invokes
the edit view for the FrontPage Page resource. It is executable by
only the editor user. If a different user (or the anonymous user)
invokes it, a login form will be displayed. Supplying the credentials with
the username editor, password editor will show the edit page form
being displayed.

Visiting http://localhost:6543/add_page/SomePageName in a
browser invokes the add view for a page. It is executable by only
the editor user. If a different user (or the anonymous user)
invokes it, a login form will be displayed. Supplying the
credentials with the username editor, password editor will
show the edit page form being displayed.

After logging in (as a result of hitting an edit or add page and
submitting the login form with the editor credentials), we’ll see
a Logout link in the upper right hand corner. When we click it,
we’re logged out, and redirected back to the front page.