Access control

Access control is about defining who is allowed to access certain resources. It takes two steps:

  1. The user is authenticated, that is, the user’s identity is determined based on some form of identification in the request, such as a session cookie.
  2. After the user has been identified, we can decide whether that user is authorized to access a certain URL or resource.


For each HTTP request that Zotonic receives, it looks for some form of credentials that can identity the user. This can be a username/password combination when the user logs in for the first time, and a session cookie for subsequent requests. When Zotonic finds some credentials, it checks them for validity. If the credentials are valid, the user is said to be authenticated and authorization can start.

The first request, that does not yet have a session cookie or whose session cookie has expired, needs to contain some credentials in order to be authenticated. The authentication controller takes care of processing login requests and checks for the presence of a ‘remember me’ cookie for automatic login. It then responds with a fresh session cookie that the client will send along with subsequent requests.

Authenticating subsequent requests, that have a session cookie, does not take place until a session is ensured (or continued) for the request context. This is commonly done by the controller handling the request by a call to z_context:ensure_all/1.

Customizing authentication

Zotonic relies on a number of notifications to perform authentication. Observe any of the authentication notifications to customize Zotonic’s authentication behaviour. See the reference for a list of all authentication notifications.


Once the request has been authenticated, authorization is initialized by sending an #acl_logon{} notification. Should the session get logged out, loosing its authentication, the authorization is cleared by sending a #acl_logoff{} notification.

Once authorization has been initialized for a request context, operations against objects can be checked by the z_acl module from Erlang code, and by the m_acl model from templates.

Protecting access to controllers

The first point of contact for authorization is in the controller’s is_authorized/2 function. Both controller_page and controller_template check for ACL options in the dispatch rule that matched the current request.

Protecting access to resources and modules

Zotonic ships with mod_acl_user_groups, a powerful user group-based authorization module. With this module you can define access control rules that determine which user groups are allowed to access which groups of content.

Customizing authorization

No matter what authorization module you use, you can always override Zotonic’s behaviour by observing the authorization or ACL notifications. This is especially useful if your application has some authorization logic that is not easily expressed in ACL rules. See the reference for a full list of ACL notifications.

Wires Developer Guide Modules

Referred by


Show a rsc as a HTML page.


Serve an uploaded-, resized- or library file.


Show a template.


This module contains the main Zotonic authentication mechanism. It contains the logon and logoff controllers, and…


Add support for editing Categories in the admin, by presenting an editable category tree at…

ACL options

Authorization checks to perform, in addition to the acl_action dispatch option, can be given in the acl dispatch option


The mod_facebook module plugs into the authentication systen to enable Facebook login on your site.


Add support for editing predicates in the admin, by presenting a list of all defined predicates on…


The mod_linkedin module plugs into the authentication systen to enable LinkedIn login on your site.


Redirect to another url.