Bob's Guides

Revolution Security Cheatsheet

Here's a quick reference to MODX Revolution security topics:

Basic Permission Stuff

• Permission — Permission to perform a specific action (e.g. save something, see the resource tree, see the element tree, upload a file, etc.).
• Access Policy — Just a list of Permissions that are checked or unchecked. When a Permission rule attaches a Policy to a User Group, the users get the checked Permissions.
• Access Policy Template — A list of Permissions that will show up in a Policy based on that template. In the Policy, the user gets the checked Permissions, but there's no way to give them Permissions that aren't in the Policy Template because they won't show in the Policy.
• User Group — A list of users. All Permissions, at this point, are granted to User Groups. No Permissions are tied to individual users. If you want to give and deny specific Permissions for a user, you have to put the user in a User Group. User Groups can be connected to policies (to control the users' Permissions) and to Resource Groups (to control access to resources).
• Resource Group — A list of resources (e.g., documents). Controlling which resources a user can see (i.e. hiding resources), and what the users can do with those specific resources (e.g., save them, edit them, view them), is done through Resource Groups. At this point, there are no Permission controls for individual resources, only for Resource Groups.
• Role — A specified authority level with an arbitrary name. Every Role has an Authority Number that determines how powerful users with that Role are. The lower the number, the greater the power. Roles in Revolution don't have Permissions attached to them like they do in Evolution. The only really important thing about Roles is the Authority Number. Each Role has a single Authority Number. Make sure that the more powerful the user, the lower the Authority Number of his or her Role. When a Policy is attached to a User Group in a Permission rule, users with the Minimum Role (or roles with an equal or lower number) get the checked Permissions in the Policy. Also (again, unlike Evolution), users can have different Roles in different User Groups, though they don't need to.
• Minimum Role — The Minimum Role (based on authority number) that qualifies users to get the checked Permissions in a Policy. When a Permission rule attaches a Policy to a User Group, the Minimum Role determines which users get the checked Permissions in the Policy. Users that meet the Minimum Role (by having a Role in the group with an authority number equal or lower than the specified Minimum Role get the checked Permissions in the Policy. Others don't.
• Context Access ACL entries (Context Access permission rules) — These connect Contexts (e.g., 'web' and 'mgr') to User Groups. Which Permissions are checked in the specified Policy will determine what the users in the User Group can do, in general, in that Context (e.g., view resources, save resources, edit snippets, create plugins, etc.). The connection also hides the Context from other users.
• Resource Group Access ACL entries (Resource Group Access permission rules) — These connect User Groups to Resource Groups. Which Permissions are checked in the specified Policy will determine what users in the User Group can do with the resources in the Resource Group. The connection also hides the resources in the Resource Group from other users.
• Element Category Access ACL entries (Element Category Access permission rules) — These connect User Groups to groups of elements (chunks, snippets, templates, TVs, and plugins) in a particular Category. They work exactly like Resource Group Access permission rules, except that they work with elements rather than resources and the element group is a Category rather than a Resource Group.
• Inheritance of Permissions — Users in a User Group with a particular Role will get the checked Permissions on the Policy with that Minimum Role specified in any ACL entry for that group. Because of inheritance, however, they'll also get the checked Permissions from other ACL entries with a Minimum Role that has an equal or higher authority number. This only operates within the User Group. Users will never get Permissions given to another User Group, no matter what Minimum Roles are specified in the other group.
• Context — A particular part of MODX. The default Contexts are the 'mgr' Context and the 'web' Context. The 'mgr' Context is the MODX Manager. To log in to the Manager, you need to belong to a User Group that has a Context Access ACL entry with a context of 'mgr'. The 'web' Context is essentially the front end, with the exception that in order to see resources under the 'web' icon in the Manager's Resource tree, you need to belong to a User Group that has a Context Access ACL entry with a Context of 'web'. Other Contexts can be created and they all work just like the 'web' Context.

Protection

• Hiding stuff. If something is unprotected, anyone can see it. Contexts are protected when a Context Access ACL entry connects a User Group to a Context. The 'mgr' Context is protected by default because a Context Access ACL entry connects it to the Administrator User Group. As a result, no one can log in to the Manager unless a) they are added to the Administrator user group, or b) They belong to another User Group that has a Context Access ACL entry with a Context of 'mgr'. The 'web' Context is also protected by default in the Manager because there is a Context Access ACL entry connecting it to the Administrator user group. No one can see the resources in the 'web' context in the Resource tree of the Manager unless a) they belong to the Administrator user group or b) they belong to another user group with a Context Access ACL entry with a Context of 'web'.
• Resources are protected when they belong to a Resource Group that is connected to a User Group with a Resource Group Access ACL entry. To see those resources, you need to a) belong to that User Group or b) belong to another User Group that has a Resource Group Access ACL entry for that Resource Group. Because there are no default Resource Group Access ACL entries, all resources are unprotected in both the Manager and the front end unless you create Resource Group Access ACL entries that protect them.
• Elements are protected when they belong to a Category that is connected to a User Group with an Element Category Access ACL entry. To see those elements, you need to a) belong to that User Group or b) belong to another User Group that has an Element Category Access ACL entry for that Category. Because there are no default Element Category Access ACL entries, all elements are unprotected by default.
• ACL entries like the ones described above only protect things in the Context specified in the ACL entry. IOW, an ACL entry with a Context of 'mgr' connecting a Resource group to a User Group will protect those resources in the Manager, but the resources will remain unprotected in the front end ('web' Context) unless there is another ACL entry for them with a Context of 'web'.

Note: I generally recommend that you *don't* add users to the Administrator User Group unless they will be very high-level administrators on the site. In other cases, putting them in separate User Groups will give you greater flexibility when designing Form Customization rules, because Form Customization rules can be tied to specific User Groups, but not to specific Roles.

Form Customization

At present, Form Customization only applies to the Create/Edit Resource panel and its various tabs. You can do some security stuff by hiding fields or tabs of the panel from everyone, or from users in specific user groups. You can also customize the panel by moving things to different tabs, by creating new tabs, and by setting captions and default values for specific fields on the panel. You can have different rules (or the same rules) for creating new resources and for editing existing resources.

Security Resources at Bob's Guides

Other Security Pages

The Revolution security system is discussed at length here.

There are Revolution security tutorials here.

The official MODX Revolution security documentation is here.

See a video on Revolution security by Shaun McCormick (splittingred) here.

Copyright © 2011-2023
Bob Ray