Section 4.2 - Access rule scope and precedence

As you already know, ACL rules can be set to only affect certain users or pages. If you want, you can even set permissions for one user on one page. This concept is called scope and is one part of the power of access control lists.

Another important part of ACL management is precedence. Because ACLs start out rather broad and slowly become more fine-grained, the more fine-grained rules need to override the broader ones. The rule in which ACL rules are processed is:

  • Rules for everybody on every page (lowest precedence)
  • Rules for users in the current user's group(s) on every page
  • Rules for only the current user on every page
  • Rules for everybody in the current page's groups
  • Rules for users in the current user's group(s) for pages in the current page's groups
  • Rules for only the current user for pages in the current page's groups
  • Rules for everybody on the current page
  • Rules for users in the current user's group(s) on the current page
  • Rules for only the current user on the current page (highest precedence)

This means that if you set a Disallow ruling on an action in a rule for everybody, effective only on the current page, that rule will override any Allow rulings that, for example, affect only the current user on every page on the site. Remember that setting a Deny ruling anywhere (even if it has very low precedence) will override any other settings for that action.

There is also a hard-coded exception to who can edit ACL rules: to prevent a site from being permanently affected by an accidental edit, administrators are always able to edit ACL rules even if something would otherwise deny it.

Note on exception to Deny rules

Since its inception the ACL system has allowed Deny rulings to be overriden if and only if they apply to the pseudo-group "Everyone" and "This entire site" is selected. This will change in 1.1.x, starting with 1.1.4. As of version 1.1.4, Deny rules will take precedence no matter what and this exception will be disabled.

Note on exception to administrators' ACL permissions

By default, Enano grants permission to administrators to edit ACL rules even if the rules themselves prevent them from doing so. This is so that if a mistake is made while editing ACLs, the site will not be locked down until the database is manually edited. Starting with Enano 1.1.3, you can comment out the line containing ACL_ALWAYS_ALLOW_ADMIN_EDIT_ACL in constants.php to enforce the ACL rule editing restrictions for administrators.

Previous Section 4.2 - Access rule scope and precedence Next
Introduction to ACLs Up one level Grouping pages for easier management