Fork me on GitHub
  1. Access Control Lists

    The new “acls” brick enables customized (to the node level) access for external visitors / customers or other needs. Compared to the groups based secure access, this is used to give users higher privileges during a single page request.


    An “Acl” is composed of four layers:

    1. target users: who can benefit from the Acl.
    2. action: what can we do with this Acl.
    3. query: on which node can we use it.
    4. exec: enhanced privileges and forced Skin during execution.

    These layers are defined as follows when creating an Acl:


    how does it work ?

    When a user visits a forbidden page (because he is not in the readers group for the node), Zena checks if this user has “acls” enabled. If this is the case Zena tries to find a rule that the user can use to access the content by searching through the list of defined Acls.

    To determine if the rule can be applied to the visited page, the rule’s SQLiss query is executed from the context of the visitor’s node. This means that the “assigned_projects” relation above would allow access to any node found through this relation from the visitor’s node.

    You can use “self” as auto-relation so that the visitor can view her own page.

    Once the rule is found, the “exec_group” is added to the visitor for the duration of the request.

    You can also force the use of a given Skin for the request. This is generally a good idea because you usually want to restrict what an external visitor sees of your project.

    Gaspard Bucher


    1. leave a comment