Last updated May 15th, 2019 | Page history | Improve this page | Report an issue
Support the team building MODX with a monthly donation.
The budget raised through OpenCollective is transparent, including payouts, and any contributor can apply to be paid for their work on MODX.
$400 per month—let's make that $500!Learn more
Security in MODX Revolution¶
Security in MODX Revolution is primarily driven by an Attribute-Based Access Control (ABAC) paradigm.
Each user in MODX has a User object, which can be assigned to any number of User Groups. Each User Group then has attributes assigned to it via Access Control Lists (ACLs). These ACLs take a variety of names depending on how they are applied, but all share one common principle - they contain a list of Permissions. These Permissions allow access to different areas or actions within MODX.
ACLs usually have the following:
- Principal - The object that is getting the access permissions. This is in MODX, by default, a User Group.
- Target - The object they apply to, for example, a Context or Resource Group.
- Access Policy - The list of Permissions that is gained by this ACL.
- Authority - The minimum Authority level required to use this ACL (see Roles).
Access is allow/deny in MODX, meaning that access is "open" by default. Once an ACL is applied to an object, such as a Context or Resource Group, those Contexts or Resource Groups will now only be accessible to the objects with appropriate Permissions.
Security Tutorial Video¶
Demonstrates by applying concepts to the MODX Sample Site to:
- Restrict RSS feed to Directors and up
- Restrict Blog to Staff only
- Create a 'secure' context for Directors and up only
- Restrict some element categories to administrators only
Example: Context Access¶
A good example is creating a Context named 'test', and assigning an ACL to it. This can be done by editing the Context, and going to the 'Access Permissions' tab. From here, you can give a User Group (say, 'HR Dept') explicit access to this Context by selecting the User Group, the 'Administrator' Access Policy, and specifying a required Authority (say, 9999 for 'Member') to have:
This will restrict the 'test' Context to users who are a Member (or Role with more authority) of the 'HR Dept' User Group.