ACL access in 2.7.3

General
1

Hello

I am really battling to get ACLs working in MODX 2.7.3

I am trying to put together a PoC where there will be around 60 users who will each need access to edit their own profiles (and not each others) and then some of the users will be granted extra permissions to edit other pages.

So I have started small with just two users.

I have created the Resource Groups (now under the Content menu) and dragged the pages I want the test users to have access to.

Ideally, I would like to show only the pages the user has edit rights to the left hand tree view.

I cloned the Admin Page Policy and reduced its access, created a Page Editors Group, gave Admin SU access, and gave my two users Page Editor (level 15) Context Access of Page Editor role and access Page Editor.

This allows the users to log into the manager screen and has disabled all the admin stuff I do not want them to do (which is a good start) but they do not see any of the resources.

Next, I create a User Group matching my test username, add my user (role 15) and give them Resource Group access (15) with an access policy of Resource.

I also create a Resource Group called AllPages to hide all of them
My issues are:

Depending on where I am through the steps, I either get a 200 error (permission died) or the page completely disappears from view. Enabling sudo for the user gives them full access.

Questions:

Should policies for Context be set to Context and Resources to Resources?

Where ever I set a role, should it be the same value (15) for all users (other than the admin) in all places (I only have one role with that value)

Is there a way to log what is going on with ACLs?

It looks so powerful that its confusing.

Kind regards

James

2

A Resource Group Access ACL entry should have a policy based in a Resource policy template (e.g., the Resource Policy template).

A Context Access ACL entry should have a policy based on a Context policy template(e.g., the Administrator Policy template).

A Context ACL entry is to control what user in a user group can do, in general, in that context (e.g., view resources, save chunks, edit snippets).

A Resource Group ACL entry is to control what, specifically, users in a particular user group can do with resources in the attached Resource Group.

There’s no tool that I’m aware of that could help you diagnose permission issues because MODX only knows that you don’t have permission. It has no way of knowing why. I tried to write such a tool and/or build it into the core, but couldn’t pull it off.

I recommend giving everyone the same role authority level unless you have a massive site with lots of subtle differences in permissions. If users need different rights, I suggest putting them in different user groups – it makes problems much easier to diagnose. I don’t know the extent to which people agree with me on this.

You might be interested in this 50-minute lecture on MODX security permissions.

3

Thanks for the description.

I need to create about 60 users each with permissions to just edit their own page. Is there a way I can do this programmatically?

Ideally, I would like to script:

  • create the user
  • create their page (all will use the same template)
  • preload some of the TVs
  • create a unique user group for the user
  • define the context ACL (assuming to restrict the rest of the site) and resource ACL to grant access to their specific page

Is this possible?

4

Yes, absolutely. You’ll also need a separate resource group for each resource if you’re going to use ACL entries.

There’s an explanation of the concepts involved here (though nothing about doing it in code).

Be sure to create a user profile when you create the user (or use the security/user/create processor with $modx->runProcessor(), which will do it for you. Note that the user processor, unlike the resource/create processor, is pretty finicky about what you send it – it requires not just a username, password, and email, but a password generation method and a password notification method (which can be set to ‘x’ if you’re not notifying the user).

Name the user group and the resource group after the username.

Instead of ACL entries, you can also protect each page with a simple snippet that forwards the user somewhere else if their username doesn’t match the some part of the pagetitle, longtitle, description, introtext, or alias fields. If you use Wayfinder or getResources to list the pages, they will list them all. That could be good or bad depending on what you’re doing.

You can also set up Login so the user is forwarded to their own page (I think it’s the &loginResourceId property). You can also create a plugin that will forward the user to the Create/Edit page panel to edit their resource.

5

Thanks Bob, that is useful.

The access to the page is for edit purposes not viewing so I need to get the ACLs working. Your video has been helpful.

Someone should write an addon which makes all this easier as the learning curve is steep.

6

Periodically, I toy with the idea of a permissions wizard, but it’s so complex that I never get around to it. Also, I proposed a simpler permission system that I hoped would appear in MODX 3, but it didn’t happen.