While working on adding a set of permissions to the ContentBlocks component, Isaac was wondering if there were any good ways of testing them out. The permission system in MODX is not very popular due to its (perceived?) complexity and the need to constantly flush permissions to see a result.

yeah, and the only reliable way i’ve found to test permissions in modx is to have one browser session with the admin changing permissions, and a separate session with the test user. and EVERY SINGLE TIME YOU CHANGE A PERMISSION, you log the test user out and back in ~ Isaac Niebeling

We had a bit of a conversation following that about how the ACLs work.

I had been using the Manage > Flush Your Permissions for refreshing permissions on my limited admin account. I simply made sure the limited user could access that, and that made my testing a lot easier than logging out and in again over and over.

That already seems like one step up, but can we do better?

It turns out that MODX has this thing called Stale Sessions. They've been introduced way back in 2.2.1 and their primary goal is to have a user refresh the "attributes" in its session (which contains a cache of many things about the user, including settings and permissions) the next time it requests a page.

I vaguely remembered that being there, but wasn't quite sure how it worked so I did a search across the MODX codebase to find instances of it, to see where it was called and how it affected the sessions. And that's when I stumbled across the processor for the Manage > Flush Your Permissions menu item.

As the name indicates, the Flush Your Permissions action will to flush the permissions of the user that is logged in. It even warns you that it doesn't affect other user sessions.

But that's a big lie.

The Flush Your Permissions processor isn't restricted to a single user. It tells all users to reload their permissions, through the Stale Sessions feature introduced in 2.2. Seriously, just check the source code if you don't believe me, there's no mention of the current user.

Following this discovery I did some testing with my new set of permissions for ContentBlocks, and indeed flushing the permissions for a full admin user also affected my limited admin user in a different browser.

Magic!

The commit that introduced this behaviour back in 2012 mentions that it doesn't yet affect anonymous sessions, as those don't have a user record that instructs them to refresh their session, so that's a bit of a caveat if you're working with ACLs for site visitors. But when tweaking client access to the manager, using Flush Your Permissions instead of logging out and back in is going to save you a lot of time.

Can we do better?

So aside from this being a time saver, is there anything else we can do with this information?

Well, one of the reasons I started looking into this was to see if there might be a way to make MODX automatically flush relevant sessions when access policies are changed or added to a user group.

I had concerns about practicality because it could take a long time on large sites, but some tests of the flush permissions feature seem to indicate that it's only a few hundred milliseconds even on sites with thousands of users. That seems totally acceptable for the convenience of not having to flush permissions manually in a lot of cases.

It turns out, the core is already doing this, but only when creating a user group using the access wizard. Not when updating a user group, or when a policy is added, updated or removed.

Sounds like some pull requests may be in order.