Skip to the content
Documentation
Version 6.x Supported

Access control

Written by Graham Brookins, Updated by Graham Brookins Maintainers: Graham Brookins
No ratings yet

Exponential decides what each person may do with users, roles and policies. Every visitor is a user, even one who has not signed in. A user gets rights from the roles assigned to the user or to one of the user's groups, and each role is a list of policies: permissions to use a module or one function of it, possibly limited to some classes, sections, subtrees or languages. Nothing is allowed unless a policy allows it.

Users and user groups are content

A user account is a content object of the class User, whose User account attribute (the ezuser datatype) holds the login, e-mail address and password hash. User groups are objects of the class User group. Both live in the content tree below the Users node (node 5), so a user's groups are simply the groups above the user's locations; a user with two locations is in two groups.

A new installation has the groups Administrator users, Editors, Guest accounts and Anonymous users. The anonymous user (site.ini [UserSettings] AnonymousUserID=10) is the user of every request without a session: its rights are the rights of everyone who has not signed in.

Roles and policies

Term Meaning
Role A named set of policies, for example Editor.
Policy Permission for one module (content), one function of it (content/read) or every module. The functions are those a module declares in its module.php (see Modules and views).
Limitation A condition on a policy: only some classes, sections, subtrees, nodes, languages, object states or siteaccesses, or only the user's own content.
Assignment A role given to a user or user group, optionally limited to a subtree or a section.

A user has the sum of all policies of all roles assigned to the user and the user's groups. Policies only add rights; there is no policy that takes a right away.

Limitations of the content functions

Function Limitations
content/read Class, Section, Owner, Group, Node, Subtree, object states
content/create Class, Section, ParentOwner, ParentGroup, ParentClass, ParentDepth, Node, Subtree, Language
content/edit Class, Section, Owner, Group, Node, Subtree, Language, object states
user/login SiteAccess

Within one policy every limitation must hold (Class Article and Section Standard means articles in Standard). Several values of one limitation are alternatives (Class Article or Folder). The Owner limitation with the value Self allows the user's own content only.

The roles of a new installation

  • Anonymous, assigned to the Anonymous users group: in the clean installation data: content/read and content/pdf in the section Standard, user/login and user/register. Site packages add more.
  • Editor, for the Editors group: creating and editing content.
  • Administrator, for Administrator users: every function of every module.
The Anonymous role in the administration, its policies written as sentences

A role seen under Users > Roles and policies: its policies as sentences, each with its module, function and limitations.

Work on copies of these roles rather than changing them, and give the smallest set that works. The policy user/login, limited by siteaccess, decides where a group may sign in: editors to the administration, members to the public site. A siteaccess with [SiteAccessSettings] RequireUserLogin=true (the administration) shows the login form to everyone not signed in; views that need no policy at all, such as user/login itself, are listed in [RoleSettings] PolicyOmitList[].

Registration and activation

Visitors can create an account with user/register, which the Anonymous role allows. New accounts are placed in the group of [UserSettings] DefaultUserPlacement (node 12, Guest accounts). With VerifyUserType=email the account stays disabled until the user follows the activation link mailed to them; Users > Unactivated users lists accounts nobody activated. An approval of new accounts by an administrator can be added with a workflow on the user registration (see Workflows).

Checking permissions in templates

{if $node.can_edit}<a href={concat( 'content/edit/', $node.contentobject_id )|ezurl}>Edit</a>{/if}
{if $node.can_create}...{/if}

{def $access = fetch( 'user', 'has_access_to', hash( 'module', 'shop', 'function', 'buy' ) )}

Every fetch of content already applies content/read, so a list shows only what the user may read. Reading the role list, building and assigning roles step by step: Roles, policies and unactivated users. Example policies: Policies.

In this section

Contributors

Comments (7 historical)

Written by readers of the earlier documentation sites, kept as they were.

  1. Example for setting policies for custom extensions

    Massimiliano Bariola ·

    Hi,
    can you provide an example about the steps needed to add user/usergroup-based restrictions for accessing different functions of a custom-developed extension ?
    ex: myextension/function1 : read access for users of usergroup A
    myextension/function2 : edit and read access for users of usergroup B
    myextension/function3 : read access for everyone

  2. User activation process

    Carl McDade ·

    It would be nice to know how the user activation process is done since there are no controls of the process readily available in the admin section.
    1) how to set the registration process for new users
    new users are created by super adminstrator
    new users must be approved (activated) by adminstrator
    new users are automatically registered and activated
    2) how to activate or de-activate a user accounts
    3) how to set what role a automatically regsitered and activated user gets

    1. Re: User activation process

      Massimiliano Bariola ·

      On point 3, I think I can help. look at site.ini file:
      [UserSettings]
      # If true it will automatically generate a password if it is empty
      # and email it to the user.
      GeneratePasswordIfEmpty=true
      GeneratePasswordLength=6
      # The ID of the anonymous user, this user will
      # be used for everyone who is not logged in.
      AnonymousUserID=10
      # Where to store newly self registered users
      DefaultUserPlacement=12
      So a registered, activated user should go into the "Guest Accounts" user group by default. of course, you may change that behavior.
      http://ez.no/doc/ez_publish/techn...ni/usersettings/defaultuserplacement
      Bye

      1. Re: Re: User activation process

        Stan ·

        My users aren't automatically being added to the Guest Accounts group, they are instead sent to the Admin's pending list. How do I bypass this step and have them automatically approved?

  3. No users...

    Eric ·

    How do I get it so a user doesn't have to login to see my site?

  4. Validation workflow

    Antoine ·

    How do I create a two-step validation workflow like the following :
    - a "contributor" create a document but cannot publish it
    - a "validator" then receives a mail or sees the document in his pending list, then he can refuse or validate the document without publishing it
    - a "publisher" then receives a mail or sees the document in his pending list, then he can refuse the document or decide to publish it (make it visible)

Comments

Add a comment

Comments are read by a moderator before they appear.