I spent a long time sorting through some confusing issues with my user groups yesterday. I enlisted the help of a MODx guru, and one of the things he was alarmed about was the fact that for each access policy in each of my user groups, I had a web context policy in addition to the mgr context policy.
For example, in user group ’myGroup’, under Context Access I’d add a context for mgr context, min role 100, access policy ’myPolicy’. Then I’d add another one for context ’web’, min role 100, access policy ’myPolicy’. For every ’mgr’ context policy in a user group, I had an identical one for ’web’.
My MODx guru was extremely concerned at this, and questioned why I had any web context policies at all... especially ones with admin-type access policies. He felt it was a big security concern to have all these web context policies lying around. He said had no web context policies in his installation.
I wasn’t sure exactly why I had them; I had just always done it that way. I spent a large portion of the day researching it. Here are the two major factors that I think led to my practice of always adding an identical web context policy for each mgr context policy.
- In Bob’s Guide for Revolution Permissions (http://www.bobsguides.com/revolution-permissions.html), which has been my #1 source of information on this matter, it says this:
...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...
- A new/clean installation of Revolution comes with two web context policies by default: User group "(anonmous)" has the "Load Only" policy for the web context, and user group "Administrator" has the Administrator policy for the web context.
So, based on the fact that 1) Bob says that user groups need a web context policy in order to see the resource tree and 2) the Administrator user group comes by default with matching ’mgr’ and ’web’ Admin policies... my practice became to match every new user group/min role mgr context policy with a matching web context policy.
At my guru’s suggestion, I began whacking these web context policies... but I discovered that, sure enough, without a web context policy, a user group can’t view the web context in the resource tree.
Furthermore, if you remove the web context policy from the Administrator group... bad things happen. First, the action never completes (you have to refresh). Then, you completely lose access to the web context.
...unless you first remove the (anonymous) web context policy. Then you can remove the Administrator web context policy safely, without losing your view of the web context in the resource tree.
All of this boils down to: if you have NO web context access policies on any groups (which requires deleting the two that come with a new install), then you don’t need to add web context policies to new user groups. When there are no policies whatsoever that lay claim to the web context, everyone can see it. Its just like resource groups... everyone can see them until you assign that resource group in a policy to one or more user groups... then anyone not in those groups can’t see the resources. It works exactly the same way with contexts (correct me if I’m wrong!)
By my thinking, the only time you’d ever NEED a web context policy would be if you were going to have a site where the entire context was restricted to a certain user group. (If just a portion of the site is, you use a resource group for those resources).
Otherwise, it seems like you can and should remove any and all of the web context policies. It makes life much simpler, since you don’t have to add one for every user group.
....but if you do stick with having web context policies, and you *do* need to add one for each new user group... what policy should you use? By my guru’s reckoning, you don’t want to have a web context policy that has any sort of admin powers (which raises the question, why does the admin group have such a policy by default?).
My initial experiments seem to indicate that the minimal policy for *seeing* the web context resources in the resource tree is the "Load / List / View" policy. Does anyone want to verify or dispute that? And (for the purposes of being able to use the manager adequately) do you ever need MORE out of the web access policy than Load/List/View?
Sorry for the long and complex post... but I’m hoping this sheds some light on what exactly the best practices are for web context policies and custom user groups.
☆ A M B ☆
MODX Staff