Hiding Specific Resources in the Manager
Permissions can be a confusing issue in MODX Revolution. There are more entities and more complex interactions between them than in MODX Evolution. The following information is for MODX Revolution and later. There is information on MODX Evolution Permissions here.
Always remember that you should never modify the standard Policies or Policy Templates provided in the basic MODX install. If, for example, you modify the standard Administrator Policy to uncheck some permissions, you will be taking those permissions away from the Admin super user. If you remove Permissions from the standard Administrator Policy Template, you will also be taking away those Permissions from the Admin super user. That goes for the other standard Policies and Policy Templates as well. Always duplicate Policies or Policy Templates and alter the duplicates.
If you need more help on Permissions, please don't email me with questions. Instead, ask your questions on the MODX Forums so that others can learn from the answers, people who know more than I do can answer them, and I don't end up answering the same questions over and over.
Before we get deeper into Permissions, a word of warning. The material on this page is a work in progress. I've tested the basic principles, but not all of the specific examples. Please let me know if something here doesn't work.
Where It's Done
It helps to understand that there are really four different parts to the Revolution Permissions system.
- Which resources users can see and what they can do with them is controlled by ACL entries.
- Visibility of the Elements tab and Files tab is controlled by specific Permissions (element_tree, file_tree).
- Visibility and organization of the Top Menu is controlled in Manager | Actions.
- Which fields show up in the Create/Edit Resource panel for particular users is controlled in Security | Form Customization.
No More Web Users and Manager Users
In MODX Revolution, there is no longer any distinction between Manager Users and Web Users — there are just Users. Controlling access in the front and back ends is done with Contexts. Users in the back end are in the "mgr" Context, users in the front end are in the "web" Context (or other Context you create). By back end, we're referring to where you are when you log in via yoursite.com/manager and work in the MODX Manager. Users in the front end, on the other hand, are visiting the site via yoursite.com and may or may not be logged in through a form in the front end of the site.
In Revolution, a User at any given time is logged in or not logged in. A User in the MODX manager is logged in and in the "mgr" Context. A User in the front end is in the "web" Context (or other Context you create) and may be logged in or not. If not logged in, the User is an anonymous user with only the Permission to "load" Documents (i.e see them).
Basic Principles
In MODX Evolution, Documents are "protected" when a Document Group is assigned to a User Group. Once that's done, only Users who are given rights to the Documents can access them. Manager User/Manager Resource Group connections only apply in the back end (in the MODX Manager). WebGroup/WebUser connections only apply in the front end of the site.
In MODX Revolution, Documents and Contexts are protected in Access Control Lists (ACLs) (more on these later). Once a Document or Context is protected by a single ACL entry, it can only be accessed by Users who are given access to it in an ACL entry and that entry will determine what they can do.
Access Permissions are listed in Access Policies. Those Policies are assigned in ACL entries with a specified Role and a specified Context. The Access Control Lists (ACLs) belong to a specific User Group and (unlike Evolution) different Users can be assigned different Roles in the group. This may sound like gibberish now, but it should become clear as we go along.
This system, while a little difficult to understand at first, gives you tremendous flexibility by allowing you to have Users in the same User Group who have access to the same Resources, but with different capabilities. With three Users in the same User Group, for example, one User might be able to see a Document in the tree, but not edit it. Another User might be able to see, edit, and save the Document but not publish, unpublish, or delete it. A third User might have full rights to the Document. Similarly, Users in a single User Group can have different capabilities in the MODX Manager.
I'll assume that you know, or can figure out, what a User, User Group, and Resource Group are ("Resource" is the official name for Documents, Weblinks, Symlinks, and Static Resources — if you don't know what all of those are, for now, just think: Resource = Document). If you are used to Evolution Permissions, however, you need some information about Contexts, Roles, Policy Templates, Access Policies, and Access Control Lists (ACLs).
In short, Access Policies are just lists of individual Permissions (e.g. save_tv, edit_document, view_document, access_permissions, etc.) that allow a user to perform a specific action or see something in the Manager. Roles are names that are associated with Access Policies with an Authority Number (more on these later). ACLs are simply lists of access rules that tie User Groups to Resource Groups and/or Contexts and to Policies. Let's look at those concepts in more detail:
Contexts
Contexts are a new concept in MODX Revolution and have many uses beyond the scope of this page. For our purposes here, we'll assume that you only have two Contexts, "web" and "mgr." The "mgr" Context is essentially the back end (MODX Manager). The web context is the front end (with a minor exception we'll get to later). If you create more Contexts later, everything you've learned here about the "web" Context will apply to them too.
By default, when you create Resources in the Manager, they will go below the "web" icon (unless you create other Contexts and place the resources in those Contexts). The Resources under the "web" icon are in the "web" Context. The "mgr" Context is simply the MODX manager. When Users are in the "mgr" Context, they are logged into the Manager. Permissions tied to the "mgr" Context determine what the user can do and see in the Manager. Permissions tied to the "web" Context limit what users can do or see in the front end of the site.
Roles
In MODX Evolution, when you create a Role, you define exactly which manager actions a user with that Role can perform. In MODX Revolution, however, the only things you set when you create a Role are the name of the Role, the Authority Number associated with that role, and an optional Description of the Role. The Authority Number of the admin Super User Role is 0. When you create other Roles, you will assign them higher Authority Numbers. The numbers are arbitrary numbers between 0 and 9999. All you really need to know about them for now, is that:
- Roles that are intended to have more rights attached to them should have lower Authority Numbers.
- You should generally avoid duplicate Authority Numbers.
- Users in a User Group will "inherit" the Permissions given to Users with Roles that have higher Authority Numbers than their roles have.
That last rule means when editing a User Group's ACL entries, you should make sure that no specific Permissions are given to higher-numbered Roles that aren't already attached to Roles with lower numbers, because the Users with the lower-numbered Roles will inherit them even though they're not supposed to have them.
When you add a User to a User Group, you give the User a Role in the Group. You control what the User can and can’t do by creating an ACL entry for that User Group that specifies what Access Policy goes with that Role.
The only function of the Role is to assign that user an Authority Number (the one associated with the Role) in the group so that the User will inherit the Permissions of other Users in the group with greater Authority Numbers.
Roles are created by going to Security | Access Controls and selecting the "Roles" tab. Clicking on "Create New" button will create a new Role. Roles can be removed by right-clicking on them and selecting "Remove Role."
Policies Templates
Policy Templates are simply lists of individual Permissions that will be shown in a particular Access Policy. Each Access Policy is based on a particular Policy Template and will only show the permissions on that Template. You can see a few of them (Important: don't edit or delete any of them now) by going to Security | Access Controls | Policy Templates tab. Right-click on a Policy Template and select "Update Policy Template." Then click on the "Permissions" tab to see the list of Permissions for that Policy Template. Notice that you can add or remove Permissions here, but this is not where you assign Permissions to users. That's done on the Access Policies tab.
Adding and removing Permissions here is usually not necessary because you can determine which users have which Permissions on the Access Policies tab by checking or unchecking them. Generally, the only reason for modifying a Policy Template is if you wish to add a custom Permission. You might, for example, want to add a custom Permission that allows users to see certain items in the top menu. Some add-on components may also make use of custom Permissions. The NewsPublisher snippet, for example has a custom Permission called allow_modx_tags that allows users to edit resources that contain MODX tags.
Access Policies
When an ACL entry is created, you select a Policy for it. That Policy will be based on a Policy Template and will show all the permissions on that Template. In the Manager, when you edit the Policy, you'll see all the Permissions listed in the Policy Template, but you can check or uncheck them to determine which Permissions the user will actually have.
If a User has conflicting Permissions (for example, the User belongs to two different groups and the "mgr" Context Permissions are different for that User) the most permissive rule will apply. So, if a user is granted a Permission in the "mgr" context in one place, no other rule in another place can take that Permission away.
In the default Revolution install, several standard Policies and Policy Templates are creates, including an Administrator Policy, a Resource Policy, and an Element Policy. Four important principles govern their use:
- Never edit the included Administrator or Resource Policy Templates. Always duplicate them, then edit the duplicate.
- Policies used in Context Access ACL entries should be based on the standard Administrator Policy Template.
- Policies used in Resource Group Access ACL entries should be based on the standard Resource Policy Template.
- Policies used in Element Category Access ACL entries should be based on the standard Element Policy Template.
There is a description of each Permission included in the Permissions list in the Manager. You can also reach the official MODX documentation on security by clicking on the "Help" button on one of the security pages.
Access Control Lists
Access Control Lists (ACLs) are lists of rules that connect User Groups to Resource Groups and/or Contexts. Every ACL entry has a Context and a Minimum Role. The Context specifies which Context the rule applies in. The "mgr" Context specifies that the rules will apply in the Manager. The "web" Context specifies that the rules will apply in the front end of the site. The Minimum Role determines which Users in the group the rule applies to.
One of the first stumbling blocks for new Revolution users is finding the ACLs. You reach them by going to Security | Access Controls | User Groups tab, right-clicking on a User Group, and selecting "Update User Group." The ACLs are available on the two right-hand tabs of the Update User Group panel. They appear as grids and, at present, the phrase "Access Control List" doesn't appear on the page. Every line in the grid is an ACL entry — a rule that specifies what users with a particular Role can do or see.
Note that it doesn't make sense to create an ACL entry until after you have created the User Group, Role, and Access Policy, that you will use in the ACL entry.
There are three kinds of ACLs: Context Access ACLs, Resource Group Access ACLs, and Element Category Access ACLs.
Context Access ACLs
Found on the "Context Access" tab of the Update User Group panel, the entries on this list control what administrative tasks Users can perform in the Context specified in the ACL entry. You create a new Context Access ACL entry by clicking on the "Add Context" button. The Permissions here govern what a user can do and see in the MODX Manager in general. The Permissions here are necessary for the Permissions below to apply. If a user does not have the right to see and edit resources in the Manager, for example, a Resource Group Access ACL entry giving the user the right to publish a resource won't apply.
When a Context Access ACL entry is created, it "protects" the specified Context from user outside the specified User Group. No users outside the group (including the Super User) will get access to that Context unless you explicitly give it to them in an ACL entry. If you create a new Context, for example, don't forget to give yourself access to it in a Context Access ACL entry for the Administrators User Group (it will usually look just like the "web" ACL entry.)
In the Administrator User Group, there are already Context Access ACL entries for both the "mgr" and "web" Contexts. That makes those Contexts "protected" by default. This has a potentially confusing side effect: when you create a new User, that User won't be able to log in to the Manager until you put the User in a User Group and give the User access in a Context Access ACL entry for that User Group with a Context of "mgr." Once you've done that, the user can log in, but won't be able to see the "web" context in the Resource tree in the Manager until you give the User access to that Context in another Context Access ACL entry for the User Group with a "web" Context (this is the exception we mentioned earlier to the principle that the "web" context only effects the front end).
Every Context Access ACL Entry specifies a Context, a Minimum Role, and an Access Policy. Users with the Minimum Role in the User Group (or one with a lower Authority Number) will be able to perform all the administrative tasks in the specified Context that are listed in the specified Access Policy.
Let's say you have a User Group called SubAdmins and you want the Users in that group to be able to use the Manager, but with restricted capabilities. Here are the steps you would take:
- First, create a Role of SubAdmin with an authority level of 9.
- Create the SubAdmins User Group and add the Users to it with a Role of SubAdmin.
- Duplicate the standard Administrator Access Policy.
- Edit the duplicate and change the name to SubAdmin.
- On the Permissions tab, uncheck any Permissions you don't want your SubAdmins to have. Removing the access_permissions Permission will keep them from changing their own security level and those of other Users. Removing the element_tree and file_tree Permissions will prevent them from seeing those tabs in the left panel of the Manager. (Note: the element_tree and file_tree Permissions are only available in the SVN and upcoming RC versions of Revolution.)
- Save the Policy
- Update the SubAdmins User Group by going to Security | Access Controls | User Groups tab, right-clicking on the SubAdmins Group and selecting "Update User Group."
- Go to the Context Access tab.
- Add an ACL entry (by clicking on the "Add Context" button). Give it the following:
- Context: mgr
- Minimum Role: SubAdmin
- Access Policy: SubAdmin
- Go to Security | Flush Permissions
- Context: web
- Minimum Role: SubAdmin
- Access Policy: SubAdmin
- Resource Group: News
- Minimum Role: Editor
- Access Policy: Resource
- Context: mgr
- Resource Group: News
- Minimum Role: Editor
- Access Policy: Resource
- Context: web
- Go to Security -> Access Controls -> Roles tab.
- Create a role called Editor with an authority level of 5.
- Click on the Policy Templates tab.
- Duplicate the Administrator Policy ; call it AdminEditor.
- Click on the User Groups tab; right-click on the Administrator User Group and select Update User Group.
- Click on the Context Access tab.
- Click on Add Context. You're creating a Context Access ACL entry; use the following settings:
- Context: mgr
- Minimum Role: Editor
- Access Policy: AdminEditor
- Save
- Click on the Users tab
- Create a new User Group called Editors
- Add the user(s) to the Editors user group with a role of Editor.
- Add the admin Super User to the group with a role of admin Super User.
- Right-click on the Editors user group and select "Update User Group"
- Add a Context Access ACL entry with a minimum role of Editor, a context of mgr and the AdminEditor Policy.
- Click on the Access Policies tab.
- Right-click on the AdminEditor policy and select Update Policy.
- Uncheck the Permissions you don't want them to have.
- Remember that users will inherit the Permissions of policies in the Context Access list with minimum roles that have a higher number than they have in the group.
- Don't forget to clear the site cache, Flush All Permissions, (and sometimes) Flush All Sessions before testing any changes.
- Note that removing the file_tree and element_tree Permissions will hide those trees completely.
- You can hide specific TVs and Create/Edit Resource form fields using Form Customization rules.
- You can also hide specific menu choices in the Top Menu using custom Permissions, but that's another tutorial.
- Go to Security -> Manage Users
- Right-click on a user and select "Update User"
- Select the "Settings" tab
- Click on the "Create New" button
- Put tree_root_id in the "Key" field
- Put Tree Root ID in the "Name" field
- Put the comma-delimited list of resource IDs in the "Value" field
- Click on the "Save" button
- Important Click on the "Save" button at the top right to save the user
- Repeat the steps above for each user
- Go to Security -> Flush Permissions
- Create a Role called "Editor" as described earlier
- Go to Security -> Access Controls -> User Groups tab
- Click on the "New User Group" button
- Put "Editors" in the "Name" field
- Click on the "Save" button
- Right-click on the Editors User Group and select "Update User Group"
- On the "Users" tab, use the "Add User to Group" button to add the users
- After adding the users, click on the "Save" button at the upper right.
- Create a Resource Group called AllDocs using the method described above
- Drag all resources at the root into that Resource Group (children will be protected automatically)
- Save the Resource Group
- Create a new Resource Group called Editor
- Drag just the resources that the Editors should see into the group
- Save the Resource Group
- Go to Security -> Access Controls -> User Groups tab
- Right-click on the "Administrator" group and select "Update User Group"
- Click on the "Resource Group Access" tab
- Click on the "Add Resource Group" button
- Resource Group: AllDocs
- Minimum Role:admin Super User
- Policy: Resource
- Context: mgr
- Save
- Click on the Save button at the upper right
- Go to Security -> Flush Permissions
- Go to Site -> Clear Cache
- Go to Security -> Access Controls -> User Groups tab
- Right-click on the "Editors" User Group and select "Update User Group"
- Click on the "Resource Group Access" tab
- Click on the "Add Resource Group" button
- Resource Group: Editor
- Minimum Role:Editor
- Policy: Resource (or EditorResource if you created that policy earlier)
- Context: mgr
- Save
- Click on the Save button at the upper right
- Go to Security -> Flush Permissions
- Go to Site -> Clear Cache
- Create a new Resource Group Access ACL entry for the Anonymous User Group with the Resource Group of the protected resources, a Context of "web," a Role of "Member" and an Access Policy of "Load Only." Do this for each protected Resource Group
- The first line of control for what resources users can see at all in the Manager is linking User Groups to Resource Groups in Resource Group Access ACL entries (with a context of mgr) — just like in MODX Evolution. It's the equivalent of linking doc groups to manager User Groups in Evolution.
- Control of what users in a User Group can do in general in the Manager (e.g., change Permissions, edit resources, create snippets, etc.) is controlled by the checked Permissions on the policy they get assigned in a mgr Context Access ACL entry.
- Control of what users in a User Group can to *with the resources in a Resource Group* is controlled by the checked Permissions on the policy assigned in for that Resource Group in a Resource Group Access ACL entry created in #1 (provided that the Context Access ACL entries give them Permission to perform those actions in the Manager).
- Control of what users in a User Group can to *with the elements in a category* is controlled by the checked Permissions on the policy assigned in for that category in an Element Category Access ACL entry (provided that the Context Access ACL entries give them Permission to perform those actions in the Manager).
- Users in a User Group inherit the Permissions of users *in that group* that have roles with higher authority numbers. That's the only function of roles in Revo.
- Hiding selected resources in the Manager is always done with Resource Group Access ACL entries with a policy that's some subset of the Resource policy and a context of mgr.
- Hiding selected resources in the front end is always done with Resource Group Access ACL entries with a policy that's some subset of the Resource policy and a context of web.
- Controlling what a user can do *with specific resources* (e.g., see them, publish them, delete them, etc.) is always done with the policy that's attached to either of the two Resource Group Access ACL entries described above.
- Hiding selected elements and controlling what users can do with them is exactly the same as in rules 1-3 except that you use Element Category Access ACL entries instead of Resource Group Access ACL entries.
- Controlling what a user can do in the Manager in general (e.g., create users, change security rules, clear the cache, edit files, see the Element tree, etc.) is always done with a Context Access ACL entry (actually the attached policy) with a context of mgr.
- Context Access ACL entry -> Administrator Policy
- Resource Group Access ACL entry -> Resource Policy
- Element Category Access ACL entry -> Element Policy
- Installing MODX
- How MODX Works
- Working with MODX resources and Elements
- Using Git with MODX
- Using common MODX add-on components like SPForm, Login, getResources, and FormIt
- MODX security Permissions
- Customizing the MODX Manager
- Using Form Customization
- Creating Transport Packages
- MODX and xPDO object methods
- MODX System Events
- Using PHP with MODX
If you quit now and log in as one of the SubAdmin Users, the login would be successful but the Resource tree at the left would be empty because we haven't given our SubAdmin users access to the "web" context. We need to create another Context Access ACL entry with the following:
Now, our SubAdmins are real Manager users with restricted access to the Manager.
Note that we could have done this another way. We could have skipped creating the SubAdmin User Group and just added all our SubAdmin Users to the Administrator User Group with a Role of SubAdmin. Then, we'd have Updated the Administrator User Group and added the two Context Access ACL Entries listed above. The results would be the same and which way you do it is a matter of your overall Security strategy. If you will be restricting which Documents the SubAdmins can see, you'll probably want to create a separate User Group for them. If they will have access to all the Documents in the Manager, you might rather add them to the Administrator User Group.
I generally recommend *not* putting other admin users in the Administrator group. Giving them their own group makes things easier to understand and will give you more options for Form Customization.
Nothing you do in a Context Access ACL will affect which documents any user can see in the front end. That can only be done in a Resource Group Access ACL specifying a Context other than the "mgr" Context.
Resource Group Access ACLs
Found on the "Resource Group Access" tab of the Update User Group panel, the ACL entries on this list control which individual Resources users can see in the front and back ends, and what they can do with those Resources. You create a new Resource Group Access ACL by clicking on the "Add Resource Group" button. As with Context Access ACLs, once you create a Resource Group Access ACL entry, you have "protected" the Resources in the specified Context. No one can see them in that Context unless they are given access to them in a Resource Group Access ACL entry.
If you specify the "mgr" Context, the Resources in the Resource Group will only be visible in the Resource tree in the Manager to Users who have been given access to them. If you specify the "web" Context, only Users who have been given access to them (and are logged in) can see the Resources in the front end of the site.
These Resource Group Access ACL entries have the same fields as the Context Access ones with the addition of a field specifying the Resource Group.
Let's say you have a User Group called "Editors" and a Resource Group called "News" containing several news articles. You want to hide the news pages from non-Editor users in the Manager. You update the Editors User group to create a Resource Group Access ACL entry as follows:
Now only members of the Editors User Group with a Minimum Role of Editor (or a role with a lower Authority Number) can see the news pages in the Manager. They will have full rights to the resources. To limit them, you can duplicate the Resource Access Policy, change the name to "EditorResource," edit the duplicate to uncheck Permissions you don't want them to have, and assign the EditorResource Policy in the ACL entry instead of the Resource policy.
As the admin Super User, when you Flush the Permissions (Security | Flush Permissions), you'll notice that the news pages disappear from the tree. To get them back, you'll either have to add the admin to the Editors User Group (presumably with Minimum role of Super User and an Access Policy of Administrator) or update the Administrator User Group to add a Resource Group Access ACL entry specifying the News Resource Group, a Context of "mgr" and again a Minimum role of Super User and an Access Policy of Administrator. Adding the admin Super User to all User Groups is usually a better strategy.
The ACL entry above will protect the news pages in the Manager, but anyone can still see the pages in the front end of the site.
Let's say that you want to hide the news pages from anonymous users in the front end. Create another Resource Group Access ACL as follows:
Now, only members of the Editors group who are logged in in the front end can see the news pages. This ACL entry will protect the news pages in the front end, but will have no effect on who can see them in the Manager.
Note that when you preview Documents from the Manager, you are still logged in as the admin Super User. To test your front-end Permissions, visit the site in another browser.
Element Category Access ACLs
These ACLs work exactly the same as Resource Group Access ACLs except that instead of protecting resources in a Resource Group, they protect elements (snippets, chunks, templates, template variables, and plugins) in a category. First, create a category by right-clicking on "Categories" in the Element tree and select "New Category". Next, drag any elements you want to protect and drop then on the new category. Finally, go to Security | Access Controls | User Groups tab, right-click on the group you want to affect and select "Update User Group". On the Element Category Access tab, click on the "Add Category" button. Select the category, the User Group's role, an access policy of Element, and the 'mgr' context. Save your work and Flush All Permissions. Elements in that category are now protected from all other users.
As with Resource Group Access ACLs, it's important to add the admin Super User to the group involved — otherwise, the admin Super User will no longer have access to those protected elements.
If you want to give the users limited access to the elements in the category (say, to allow them to edit but not delete the elements), duplicate the Element policy, assign that policy instead of the original and uncheck any Permissions you don't want them to have.
Controlling What Users Can Do and See in the Manager
If you simply want to limit the user's actions in the Manager without hiding any resources or elements, what you want to do, in a nutshell, is to duplicate the standard Administrator policy. Then put users in a User Group and update that User Group in Security -> Access Controls. Create a Context Access ACL entry for the mgr Context with the duplicate policy you created (and a role with a higher authority number than the Admin). Then edit the duplicate policy and uncheck any Permissions you don't want them to have.
That will limit what the users can do in the Manager.
If you need finer-grained control and only want to limit what users can do with some, but not all, resources or elements, you can put specific resources in Resource Groups and specific elements in Categories, then do something similar to the above, but duplicate the Resource policy (for resources) and the Element policy (for elements). You then create Resource Group Access ACL entries and Element Category Access ACL entries with the two respective policies and edit the policies to uncheck Permissions as above. That will limit what users can do with the specific objects in the Resource Group or element category.
You can also do a lot by just customizing the Manager. You can hide parts of the Create/Edit Resource form using Form Customization. Hide parts of the Resource tree by setting a tree_root_id user setting. Hide the Element tree and File tree altogether by unchecking the element_tree and file_tree Permissions in the duplicate admin policy. You can also use custom Permissions to hide various Top Menu items and subitems.
Limited Manager Users Who Can See All Documents
Sometimes, you want users who can see all the resources in the tree, but have limited rights in the Manager. To limit the users' actions in the Manager, you don't need any Resource Groups. You just need to assign them a policy in the mgr context that has fewer Permissions checked.
Here are the steps for an example where you want a group of Editors who are not super users:
If you need to give different Permissions to different users, create a new role with a different authority number and a new policy for each group of users that will share a set of Permissions and repeat the steps above to create a Context Access ACL entry for each group with the appropriate policy.
Further Tips:
Limiting Manager Users to a Subset of Resources using tree_root_id
Note: tree_root_id is deprecated in MODX 2.2.0 and beyond, but I've left this here because some of the information is still useful
Sometimes, you want to have a group that can only see some of the resources in the Manager. If you trust your users, you can create a tree_root_id user setting for each user. The tree_root_id setting is a comma-delimited list of resource IDs. The user will only see those resources and their children in the tree. This is not a fully secure option because users who can guess the Manager URL of a resource can still edit it.
To create a tree_root_id user setting:
The user(s) should now only see the resources in the tree that you have assigned to them.
Limiting Manager Users to a Subset of Resources using User and Resource Groups
There is a tutorial on hiding resources in the Manager here.
There is a tutorial on creating user-specific pages (e.g. restricting multiple users to their own individual pages) here.
To truly limit the users' access to resources, you need employ User Groups and Resource Groups. The basic process is to put all the resources of the site into a Resource Group and protect them by creating a Resource Group Access ACL entry linking that Resource Group to the Administrator User Group. That protects the resources from all users that are not in that group. Then, create a User Group for the limited users and a Resource Group containing the resources they can access and link the two with another Resource Group Access ACL entry. This allows those users to see those protected resources.
This technique works best if the users you want to limit are *not* members of the Administrator User Group. You can make them members of the Administrator group with a higher authority number than the one used to protect the resources, but that will limit what you can do with Form Customization, since Form Customization rules are often based on User Group membership.
Remember that to log in to the Manager and see any resources in the web context, the limited users must have a Context Access ACL entry for both the web and mgr contexts as described earlier on this page
Let's imagine that you want to limit members of the Editors User Group to a specific set of pages. Here's how you'd do it.
Creating the User Group
Creating AllDocs Resource Group
You can Download and install the DefaultResourceGroup plugin to automatically put all future new resources into the AllDocs group. Set the plugin's drg_groups property to AllDocs
Creating the Editor Resource Group
Protecting the AllDocs Pages
All resources should be protected from non-Administrators at this point. If you log in as an Editor user, you shouldn't see any resources in the tree. The next step is to give the Editors access to their resources.
Giving the Editors Access to Their Resources
If you log in as an Editor user, you should now see just the resources in the Editor Resource Group in the tree. To review, we created an AllDocs Resource Group and protected all its resources by connecting them to the Administrator User Group with a Resource Group Access ACL entry. Then, we created the Editor resource group and gave the Editors access to its resources by creating a Resource Group Access ACL entry connecting the Editor Resource group to the Editors User Group.
There's a great graphic created by MODX user lithiumlab showing the process of giving a User Group access to a specific set of resources here
Manager Actions in the Front End
If you don't have snippets or plugins that perform Manager actions when a page is visited in the front end, such as clearing the cache or changing security settings, you don't need to worry about this section. Most regular snippets (e.g. Wayfinder, BreadCrumbs, and most custom snippets) will execute fine. All code will also execute if you are previewing the page from the Manager as the admin Super User.
Remember, though, that by default the "web" Context is protected by the ACL entry in the Administrator User Group. Users in the front end who are logged in, will need to be given the proper Permissions with a "web" Context Access ACL for their User Group in order for code that performs Manager actions to execute. It still won't execute for anonymous (not-logged-in) Users unless you also create a Context Access ACL for the anonymous User Group giving them the appropriate Permissions in the "web" context.
Unauthorized Versus Error Page
This is a change from MODX Evolution. In Revolution, if a web page is protected in the front end so that only logged-in users can see it, the default behavior is for anonymous users to be redirected to the Error (page not found) page rather than the Unauthorized page when they try to access the resource. In Revolution, if Users don't have the "load" Permission for a resource, it's as if it doesn't exist — thus the "page not found" response. If you would like them to be sent to the Unauthorized page instead, you can do the following:
Note that this won't solve the problem for users who are logged on in the front end but are trying to access pages they are not authorized to see. To solve it for those users, add them to the User Groups authorized to see the pages, but with a Role of "Member." Then, Update the User Groups and add another Resource Group Access ACL entry for the group with the Resource Group set to the protected resources, a Minimum Role of "Member" and a policy of "Load Only."
A Quick Summary
Here's a quick summary that might help if you're still confused about using Revolution Permissions
Still Confused?
Let's take another crack at that from the perspective of what you want to do and set some firm rules:
Once you've create the appropriate Roles, Users, User Groups, Resource Groups, and Policies, all of the steps above are done by going to Security | Access Controls | User group tab, right-clicking on a User Group, and selecting "Update User Group."
The necessary ACL entries are created on either the Context Access tab (to control what users can do in general in the manager) or the Resource Group Access tab (to control which resources users can see and what they can do with those specific resources).
Where's My Policy?
When you try to add a policy in an ACL entry, you will only see policies that are appropriate to the kind of ACL entry you're creating. If you create a duplicate of the Resource Policy, for example, and are creating a Context Access ACL entry, you won't see your policy because it is inappropriate there. Here is how the policies line up:
Be sure you duplicate the correct policy for the type of ACL entry you're going to create.
Security Resources at Bob's Guides
Other Security Pages
There is a MODX Revolution security system cheatsheet 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.
My book, MODX: The Official Guide - Digital Edition is now available here. The paper version of the book may still be available from Amazon.
If you have the book and would like to download the code, you can find it here.
If you have the book and would like to see the updates and corrections page, you can find it here.
MODX: The Official Guide is 772 pages long and goes far beyond this web site in explaining beginning and advanced MODX techniques. It includes detailed information on:
Go here for more information about the book.
Thank you for visiting BobsGuides.com
— Bob Ray
