ACL, UserGroups, ResourceGroups, Permission some confirmations or doubts

Support
1

ACLs and groups have always been quite challenging for me, but more or less I’ve always managed to solve them. :grinning_face:

Now I’ve come across them again, for the first time with version 3.x.x, and I’ll provide a summarizing example of my cases along with some questions or requests for confirmation.
I may have always gotten everything wrong, but fortunately, it worked for me. :upside_down_face:

My sample situation is as follows.
Multicontext (multilingual) site with resources that only registered users can see on the front-end (private) and resources that only super admins can see in the manager (hidden), such as sitemap or clearcache.The private and the hidden are respectively inserted in the resource groups G.R.Private and G.R.Hidden

web

  • home

  • editor

  • private

  • hidden

ita

  • home_it

  • editor_it

  • private_it

  • hidden_it

The user groups are 4: the classic anonymous, super admin and the editor group, with their respective default policies with minor modifications, and finally, the one for registered users (front-end, G.R.Private).

Here are the permissions of the various groups to enforce what was initially written.

ANONIMOUS (NO Manager Access)
Context
web role: member 9999 policy: Load Only
ita role: member 9999 policy: Load Only
1- this is solely to make the unauthorized and error pages function correctly; if I don’t insert them, it would always go to the error page, right?
Resource Groups
G.R.Private role: member 9999 policy: Load Only context: web
G.R.Private role: member 9999 policy: Load Only context: ita
2- this for the same reason as point 1, or can I omit it too?

ADIMINISTRATOR (Super Admin)
Context
MGR role: 0-Super User policy: Administrator
web role: 0-Super User policy: Administrator
ita role: 0-Super User policy: Administrator
3- For contexts other than mgr, I could have simply put member9999 and Load List and View, as they only pertain to the front-end site display, right?
Resource Groups
G.R.Private role: 0-Super User policy: Resource context: web
G.R.Private role: 0-Super User policy: Resource context: ita
4- In this case, could I also have set the policy as Load, List, and View?
G.R.Hidden role: 0-Super User policy: Resource context: MGR
5- This setting makes the resources within G.R.Hidden visible only to this group in the manager, while in the front-end they are visible to everyone, correct?

REGISTERED USERS (NO Manager Access)
Context
web role: member 9999 policy: Load, List and View
ita role: member 9999 policy: Load, List and View
6- For front-end contexts for registered users, the Load, List, and View policy is sufficient, correct?
Resource Groups
G.R.Private role: member 9999 policy: Load, List and View context: web
G.R.Private role: member 9999 policy: Load, List and View context: ita
7- This allows registered users to see private resources on the front-end; I don’t need to set it as a resource policy?

EDITOR
Context
MGR role: 50-Editor policy: Content Editor
web role: member 9999 policy: Context
ita role: member 9999 policy: Context
8- For contexts other than mgr, I could have simply put fot policy Load List and View (and not Context), as they only pertain to the front-end site display, right?
Resource Groups
G.R.Private role: 50-Editor policy: Resource context: web
G.R.Private role: 50-Editor policy: Resource context: ita
9- In this case, could I also have set the policy as Load, List, and View?
10- This is more than enough to show private resources to editors logged into the manager. I don’t need to add them to the Registered Users group, right?

I admit that it will be quite tedious to respond to everything. :blush:
If it happens, I will provide a detailed summary post that could be useful to other users.

2

That’s a lot of questions. :wink:

Your situation is complex enough that I hesitate to advise you.

First, if you haven’t done so, be sure to do all your testing in a separate browser where you’re not logged into the Manager.

Here are some answers, but some of them are guesses that you’d need to test.

  1. Yes.
  2. You can omit those if users get that permission from another policy that applies to them.
  3. I don’t think so if you want them to be able to edit resources in those contexts.
  4. Same as 3.
  5. Yes.
  6. Yes
  7. Yes (I think)
  8. Yes, but load, list, and view also apply in the Manager context without them you can see things in the tree or edit them.
  9. Same as 3 unless they don’t need to edit the resources.
  10. I think so, unless they need to see the gr-hidden resources in the front end.

I apologize if I’m misunderstanding your strategy. Resources that are in a Resource Group that’s connected to a User Group are hidden from all other users who are not in the User Group unless their group is also connected to the Resource Group.

My general strategy is to put the admin super user in every User Group with a role of super user, so you don’t need give them specific access to any resource groups, and you don’t end up hiding resources from yourself. That said, as long as what you’re doing works (testing as I suggest above), I wouldn’t make any changes.

You might be interested in this video from a presentation I did on MODX security at MODXpo a while back, but fair warning – it’s almost an hour long. It may have an error in it because at that time, I wasn’t aware that each Role has to have a unique authority level.

I sense that you may have some confusion about the difference between Object policies (e.g., Resource) and Context Policies (e.g., Administrator), which the video might clear up.

3

Thank you very much, as usual! :+1:
Actually, the way I organize things, the situation I’ve described happens to me quite often.

I always test on various browsers and even on different PCs for safety. :grinning_face:

To have more redundancy in security, I always applied the listed permissions, but I realized through testing that Load, List, and View are often sufficient for editing.
For example, if the editors have the ability in their MGR policy to modify resources, they can do so even if I set Load, List, and View as the policy in other contexts and as the policy for resource groups.
I’m never quite sure if the mgr context covers the entire manager(v. A), including other existing contexts (so policies on other contexts concern the front-end), or (v. B)if the other contexts are separate in managerial aspects and therefore the general policies of the mgr need to be confirmed in the other contexts.
For my example
EDITOR (v. A)
Context
MGR role: 50-Editor policy: Content Editor
web role: member 9999 policy: Load,LIst and View
Resource Groups
G.R.Private role: 50-Editor policy: Load,LIst and View context: web

EDITOR (v. B)
Context
MGR role: 50-Editor policy: Content Editor
web role: member 9999 policy: Context
Resource Groups
G.R.Private role: 50-Editor policy: Resource context: web

In both versions above, editors can view and modify resources (and Private Resource) in the manager within the web context.

4

Right, because the Content Editor policy gives them that ability. Permissions are basically additive, so if you get a permission somewhere, it can’t be taken away by another ACL entry.

5

You have resolved all my doubts, thank you!
Basically, I should have set resource if the editor’s policy did not allow modifications.
Thanks again!