Revo Security: Front-end member access to specific resources in alternate context (not web)

HI,

I'm trying to create multiple overlapping member-only sections (that is, after login to the front-end, there are 3 levels of access to various resources) of a website in a context (named prg) which is also acting as a subdomain. I've used the tutorial in the MODx documentation (https://rtfm.modx.com/revolution/2.x/administering-your-site/security/security-tutorials/making-member-only-pages), but this hasn't seemed to have any effect. The only thing I've noticed is that prg is listed in the anonymous ACL under context access (Member-9999, "Load, List, View") - if I remove this, I lose all access to the prg context entirely. However, I think keeping this context access is also allowing full access to the secure resources.

How can I retain context access to the non-secure pages, but restrict access to the secure to those who login with specific usergroup permissions to the different resource groups? Is there a tutorial regarding this that I can follow? To clarify, no access to the Manager is required, this is all front-end security.

I'm using MODx 2.4.0.

You'll need to give the anonymous group load-list-view to the context, and load-only to the resource group.

Thanks sottwell. That's given me ability to lock anonymous users from the secured area. However, I've played around with it further, and I'm not now able to restrict the 1st level users from the 2nd or 3rd level resources once they are logged in. What am I missing here?

For reference: at the moment my user groups look like this:

(anonymous):

• Context Access: prg, member 9999, load list view
• Resource Group Access: Level 1 Resources, member 9999, Load only, prg
• Resource Group Access: Level 2 Resources, member 9999, Load only, prg

Level 1 Users UG:

• Context Access: blank
• Resource Group Access: Level 1 Resources, member 9999, load list view, prg

Level 2 Users UG:

• Context Access: blank
• Resource Group Access: Level 2 Resources, member 9999, load list view, prg

[ed. note: moniarde last edited this post 8 years, 7 months ago.]

Bump. Looking for ways to allow front end users to login and access resources corresponding to their usergroup:
Level 1 users can access Level 1 resources.
Level 2 users can access Level 1 and level 2 resources.
Level 3 users can access Level 1, level 2 and level 3 resources.

Is this possible? If not, please advise...

It's definitely doable. One key is to remember that resources can be in more than one resource group, so the groups could be:

LowAccess (contains only group 1 resources)
MediumAcces (contains all resources in groups 1 and 2)
HighAccess (contains all resources in groups 1, 2, and 3)


Now you can give the users in group 1 access to the LowAccess resource group, the users in group 2 access to the MediumAccess resource group, and group 3 users access to the HighAccess resource group.

Be sure to add yourself to the group 3 user group.

Thanks Bob. So I see that you're suggesting the following process:

- add users to only one user group, and add resources to all of the resource groups as required

rather than

- add users to multiple user groups, and add resources to just the resource groups that define their level of access.

Are you recommending that the first process is better than the other? Given that I want users to be able to purchase increased levels of access, the first option seems less intuitive. And if I'm using the DefaultResourceGroup to set the resource groups, then the first option would seem to make that snippet less effective. I would imagine it would be easier to manage users in their groups than resources into their groups.

Also, the problem I'm currently seeing is that when the user (assigned to level 1) logs into the the front-end membership page, they can still see all of the secured resources (levels 1, 2 and 3), instead of only the level 1 resources. However, when they have not logged in, all of those secured resources are hidden as expected and desired. I would expect that when the level 1 user logs into the membership page, they only see level 1 resources. (In fact, what I'd really like to do is to be able to list all of the resources on the membership page, and "disable" access to the higher level resources, without the user being able to browse to those resources at all. But that is seeming unlikely at this stage.)

It crossed my mind that, because I'm assigning multiple ACLs referencing the same resource group to various user groups, that perhaps an ACL in the level 1 user group is overriding the other ACLs. Is this a possibility? And is there a potential fix for this through roles, or do roles play little part in front-end security?

What's the solution to being able to hide level 2 and 3 resources to a level 1 user, then being able to hide only level 3 resources to a level 2 user, etc, once they log in?

I think my way is easier, but I wouldn't be my house on it.

For my method, when a user upgrades, you just have to add them to the new group(s) and probably remove them from their current group (it won't hurt to leave them there, but you might want to, for example, email all members of a particular group or do something else with them).

You have a point about DefaultResourceGroup (though you gain DefaultUserGroup to put everyone in group 1). You can certainly have three separate resource groups with no overlap, but it will double the number of ACL entries you need and that might slow things down a little when they're evaluated.

The problem you're describing shouldn't happen (unless I've got something wrong).

Connecting the group 2 resources to the group 2 user group should protect those resources from anyone who is not in group 2, unless they're granted access elsewhere. The same should be true of group 3.

As long as the group 1 users only have an ACL entry connecting them to the LowAccess resources, they shouldn't be able to see the group 2 or 3 resources.

-- Be sure you flush both permissions and sessions before testing.

-- Always test from another browser where you're not logged in to the Manager.

-- Make sure you got rid of your previous ACL entries,

Thanks Bob. Yes, I'm testing from another browser, and the only ACLs I'm currently using are these:

For reference: at the moment my user groups look like this:

(anonymous):

Context Access: prg, member 9999, load list view
Resource Group Access: Level 1 Resources, member 9999, Load only, prg
Resource Group Access: Level 2 Resources, member 9999, Load only, prg

Level 1 Users UG:

Context Access: blank
Resource Group Access: Level 1 Resources, member 9999, load list view, prg

Level 2 Users UG:

Context Access: blank
Resource Group Access: Level 2 Resources, member 9999, load list view, prg

There doesn't seem to be a Flush Permissions or Sessions menu item in 2.4.x, only a Flush Your Permissions to log me out, or a Logout All Sessions, which logs all of us out. I am saving and clearing the cache everytime I make a change, and I do notice changes then.

I guess I can test your method, don't really have anything to lose atm...

Right, "flush all sessions" is now called "logout all sessions." In many cases, changes to the permission system don't take effect until you flush the session data, which means logging everyone out.

Bob, even using Logout All Sessions, there is no change to viewable items in the secured area - users are restricted from the resource groups until they log into the common area, but they then have access to resources they are not assigned to. My permissions are the same as listed above - what am I missing here?