Magnolia 4.5 reached end of life on June 30, 2016. This branch is no longer supported, see End-of-life policy.

Page tree
Skip to end of metadata
Go to start of metadata

There are several ways you can define permissions. You can either have many groups with one role each or only few groups which several roles. From a technical point of view, it is irrelevant whether you have one role with many ACL entries or many roles with one entry. It is more or less the same amount of content. Therefore, focus on easy-to-read scenarios!

One type of strategy is to first "open" access (allow access to all pages) and then "close" (deny access) systematically. Another is vice versa, first "close" access and then "open" systematically.

Open/Close

Assume the following website structure:

/en
   /section1
   /section2
   /section3
   /section4

An "open/close" strategy could have the following ACL:

Permission

Path

Read/Write

/

Read only

/en/section1

Read only

/en/section2

Deny access

/en/section4

First we open access to the Web site, then close it systematically by defining read-only permissions for /en/section1 and /en/section2 and denying access to /en/section4.

If you attach this ACL to a role and add a user to the role, the user can read sections 1 and 2, edit section 3 (by virtue of being granted write access to /) and is denied access to section 4.

You can achieve similar permissions as above, but with several roles:

Role

Permission

Path

Managing Editor

Read/Write

/

Section 1 Reviewer

Read only

/en/section1

 

Deny access

/en/section4

Section 2 Reviewer

Read only

/en/section2

 

Deny access

/en/section4

Having many roles allows flexibility in defining different groups. On the other hand you get more complexity.

Close/Open

Assume the following website structure:

/en
   /section1
   /section2
   /section3
   /section4

A "close/open" strategy could have the following ACL:

Permission

Path

Deny access

/

Read only

/en/section1

Read only

/en/section2

Read/Write

/en/section3

First we close access to the Web site, then open it systematically by defining read-only permissions to sections 1 and 2, and write permission to section 3.

If you attach this ACL to a role and add a user to the role, the user can read sections 1 and 2, edit section 3 and is denied access to section 4.

Effectively, this strategy has the same outcome as the "open/close" strategy above for a user who needs to be able review content in sections 1 and 2, edit section 3, but should not be able to access section 4 at all.

  • No labels