Permissions caching in Revo

Hi,

I’ve built a website running MODx Revo 2.0.7 which has a number of users divided across 5 user groups. For simplicity let’s say they’re called "UG1"-"UG5". Users can be a member of any combination of groups, e.g. UG1 and UG3, or UG1 UG2 and UG4, etc...

This is all working fine and I am able to limit what these users see when logged in based on their access.

I’m in the process of building a Custom Manager Page which will list all of these users in a table in the Manager. This CMP takes into account the user groups I’ve created and various extended fields that these users have been given.

The problem I’m having is when I update the user groups of a user. Both the CMP and the front end do not update with the latest permissions unless I flush all sessions and log everybody out. Is there a modx function I can use to retrieve the uncached user groups for any particular user?

In fact, could I just turn off permissions caching entirely? or would this have a detrimental effect on performance?

At the moment I’m using $user->getUserGroups() whenever I need to check the user groups, where $user is a modUser object of course.

thanks in advance for any help.

Quote from: phatphug at Jan 27, 2011, 12:15 PM

The problem I’m having is when I update the user groups of a user. Both the CMP and the front end do not update with the latest permissions unless I flush all sessions and log everybody out. Is there a modx function I can use to retrieve the uncached user groups for any particular user?

In fact, could I just turn off permissions caching entirely? or would this have a detrimental effect on performance?

It would indeed have a very detrimental effect on performance. Unfortunately, the only way to refresh another user’s session is to flush them all and force the logout, or be logged in as that user. I’ll have to consider if there is a way to send a message that would trigger a individual reload of each users’ access permissions the first time they accessed the site, once you were done modifying the permissions, but I imagine this might require refactoring the permission caching to not rely on the sessions, or some add-on development using a plugin and the registry service.

Quote from: phatphug at Jan 27, 2011, 12:15 PM

At the moment I’m using $user->getUserGroups() whenever I need to check the user groups, where $user is a modUser object of course.

This data is cached in the session and that method does not have a way to force getting the latest data. If you want, enter an improvement ticket requesting a way to empty the session of all the data other than what is required to remain logged in, and/or to provide parameters on these methods to reload the data rather than returning from session automatically.

Thanks for your input Jason, I figured disabling caching would be a bad idea.

I’ll submit a feature request for getUserGroups.

I think the only temporary workaround for this would be to manually query the database table `modx_member_groups` and pull out the raw data.

Update:
On further thought about this, the MODx manager must be able to get around this issue somehow. When a users access permissions are changed in Security -> Manager Users. The "Access Permissions" tab doesn’t appear to have a caching problem.

Quote from: phatphug at Jan 28, 2011, 04:49 AM

Update:
On further thought about this, the MODx manager must be able to get around this issue somehow. When a users access permissions are changed in Security -> Manager Users. The "Access Permissions" tab doesn’t appear to have a caching problem.

These are actually unrelated—though changing user groups can affect access permissions, they are cached separately for the current user in their session. This is a per user cache, so if I get the groups for two different users, that data is cached in my session. This method was originally intended for use with the current user, not as a user management method, which is why it caches the user group data in the user session. Similarly, all of the access policies a user is assigned by way of their group memberships are cached in their own sessions.

And yes, you can simply perform a query to get their latest group memberships, but they will still have to have their session refreshed before any changes to those memberships will affect their access to anything.