Changes in group membership aren't causing authz invalidation
Description
is related to
relates to
Activity
Earle Nietzel June 3, 2014 at 8:20 AM
look at r310018
Matthew Jones May 30, 2014 at 2:56 PM
So I'm kind of confused about the default for this setting for 10 and wondering if it maybe could be related to issues like SAK-26294?
In some places useLegacy looks like it's true, in other places it looks like it's false.
For instance in BaseSiteService (and SakaiSecurity, ClusterEventTracking and BaseAliasService) it's set to false
boolean useLegacy = serverConfigurationService().getBoolean("memory.use.legacy", false); // TODO remove this after 10 merge
But in BaseMemoryService it's true
boolean useLegacy = true; // for 10.x release
if (serverConfigurationService != null) {
useLegacy = serverConfigurationService.getBoolean("memory.use.legacy", useLegacy);
So should the default for 10 be true or false? I don't see it overridden in kernel.properties. I don't see a commit here either.
Aaron Zeckoski May 15, 2014 at 9:23 AMEdited
10.x nightly is not running legacy caching for some reason so I will update it the code to force it.
boolean useLegacy = true; // for 10.x release
Oh wait, bad logic in there, it should be fixed now for 10
Matthew Buckett May 15, 2014 at 9:20 AM
I don't see this issue on a standard 2.8.x install
Details
Details
Priority
MajorAffects versions
Components
Assignee
KERNEL TEAMReporter
Matthew Buckett
On the nightly sakai-10 server it appears that when a change is made to a group the SecurityService cache isn't invalidated.
Steps to reproduce:
Create a new site with the resources tool and add a maintainer and an accessor.
Create a group in the site but don't make anyone a member of the group.
Create a folder in the resources tool and make it only available to the group that's just been created.
Login to sakai as the accessor (private browsing window) and visit the resource tool in the newly created site, verify that you can't see the folder (as you aren't a member of the group).
Switch back to the maintainer and add the accessor to the newly created group.
Refresh the accessors view of the resources tool (using tool reset), the accessor should now have access to the group protected folder. But in my testing they didn't.
This looks to be related to the cache work as logging in as an administrator and resetting the caches means the group protected folder appears.