[Plugin: Page Security by Contexture] Remove User from Group Still can access …

In all honesty, I haven’t tested on MS at all – although I’ve had folks send me occasional MS fixes, and I’ve worked those in as I get them… so there’s definitely people using it with MS.

My first thought is that these are two most likely culprits (more detail to follow):

• The “Registered Users” group may be attached to the content or one of it’s ancestors. If so, the user would have access if there were no additional requirements.
• Server, MySQL, or WordPress caching may be preventing PSC from getting the most up-to-date data from the db. Try clearing your caches after removing the user, or try temporarily disabling any caching tech you’re running.

Here’s a little more detail that might help us figure out what’s going on and where:

When PSC determines access, it generates two arrays. One array contains the necessary permissions for the current page (including permissions for all ancestor pages), and the other contains the current users groups.

PSC then compares the two arrays, ensuring that at least one of the groups shows up at each requirement point in the permissions array. Each array is generated on demand from the permissions & membership data in the database – so in order to pass the security check, the user has to have a group record in the PSC relationships table.

Here’s some things I would run through, just for the purpose of collecting more info:
1) Create a new user.
2) Log in with that user and see if they can access restricted page (they shouldn’t – but if they can, stop here and let me know).
3) Add the user to a group and attach that group to a restricted page
4) Try to access the restricted page with the now-authenticated user (it should work)
5) Remove the user from the group
6) Try to access the restricted content again. If they can still access the content at this point, read on.

If you made it all the way to step 6, and the user can still access the restricted content, check for the following:
1) Do you have any kind of WordPress caching enabled? This might be saving the data from the group access query even after the database has changed. This means PSC would be checking against “old” data.
2) Do you have any database/php/server caching enabled? This also might result in “old” data being used in the security check.

If you suspect either of the above cases is true, then there’s some things you can try to confirm or debunk…
1) Disable the caching, or clear the cache after user check in step 6 and see if the access is removed afterward.
2) If you have direct access to the database, check the wp_ps_group_relationships table and ensure the user is no longer in the specified group. If the record isn’t there, it’s probably a caching issue… particularly if the user didn’t have access before they were added to the group.

I know that’s a LOT. But hopefully it helps. If you still have problems after trying all this, please reply and I’ll see what else I can do to help.

Wow Veraxus – Thanks for super prompt and thorough response … in between my original post and your reply, i did a bunch more testing this AM and ultimately got it working thus we can consider issue RESOLVED with MultiSite 3.1 (although i’ll be upgrading network to 3.1.1 later today) …

i think you were right in that something was getting hung up and i believe it was when a role had been assigned the group …

for instance, i had used Justin Tadlock’s Membership plugin to create a new role called “teachers” so even though i turned off his plugin, that role was still in the database …

so when testing PSC, i created a group called “mysillygroup” and assigned the Role Affiliation to the role of teacher … and that is where i got in trouble when i removed the test-user from that group, since the role of teacher was still assigned to the mysillygroup, said user (or any other user with the teacher role) could still access the private content because their default role was teacher (as was the group) …

so this morning i started over again with just the four default roles (editor, author, contributor, subscriber) and first RESET USER ACCESS MANAGER thus essentially started with clean slate … and yes, all then worked as advertised …

so then i went back with custom roles and to Justin’s Member plugin, reactivated it, assigned some new responsibilities to teacher role, went back to PSC and started adding and removing test-user with teacher role as well as other default roles and that is when i realized that if a group shared a default role (of say subscriber or teacher) then it did not matter if i removed a user from that group or not since that role was associated with said group thus user was auto affiliated with group because of their role …

whew … suffice it to say i really appreciate this forum and plugin authors like yourself and plugin teams like PSC that really bring the WP experience to a higher level of performance for the rest of us …

accordingly, a BIG THANK YOU and to be continued … cordially, chuck scott

ooops … just realized that my post above mixed up PSC experience with UAM (user access manager plugin that i was also testing on another sub site on the network) … and yes, after clearing out custom field values from user meta tables and starting over, all seems to be working with both plugins on both sites on network (that is PSC on site-A; UAM on site-B) … not sure which one i’ll ultimately go with as tough call but just thought i’d share in case others might follow this thread and say, “what was he talking about Reset User Access Manager with PSC” … suffice it to say time for homeboy to take a break and clear the coding fog from my head :>0 … thanks again … cheers – chuck scott