[sakai-core-team] Change in role not flushing permissions

[Earle Nietzel]

So I double checked the changes in KNL-1325 and it does not affect this...

What I found was that this cache
org.sakaiproject.authz.api.SecurityService.cache
is causing the issue your seeing.

This is the method that is being checked in SiteAction
boolean allowUpdateSite = SiteService.allowUpdateSite(siteId);

which corresponds to this service method:
org.sakaiproject.authz.impl.SakaiSecurity.checkAuthzGroups(String, String,
String, Collection<String>)

Next would need to look at invalidation around this cache, but thats all I
have for today!


On Mon, Mar 16, 2015 at 9:35 AM, Steve Swinsburg <steve.swinsburg at gmail.com>
wrote:

> Earle, I experienced this on trunk and its reproducible.
>
> 1. As admin, add a user to a site with access role.
> 2. In another browser, login as that user and go to the site gradebook.
> You'll see it as a student.
> 3. As admin, change role to maintain.
> 4. As other user, refresh gradebook. Still student. Navigate to site info,
> you can add participants.
>
> Screenshots attached to https://jira.sakaiproject.org/browse/SAK-29153
>
>
>
> On Tue, Mar 17, 2015 at 12:26 AM, Earle Nietzel <enietzel at anisakai.com>
> wrote:
>
>> Hi Matt,
>>
>> KNL-1325 is more than likely not the cause as the only thing that changed
>> is moving the refreshAuthzGroup() method into a separate thread that
>> processes every minute (previously it was on the user's request thread).
>>
>> The optional authz.cacheGrants which was defaulted to true has been
>> removed. So if you had this set to false you could experience what your
>> seeing.
>>
>>
>>
>>
>> On Fri, Mar 13, 2015 at 11:06 AM, Matthew Buckett <
>> matthew.buckett at it.ox.ac.uk> wrote:
>>
>>> This was on trunk and in a site that didn't involve any provider so I
>>> thought KNL-1325 shouldn't affect it as I was under the impression that was
>>> todo with refreshing users/roles from the providers.
>>>
>>> On 13 March 2015 at 15:02, Earle Nietzel <enietzel at anisakai.com> wrote:
>>>
>>>> Thanks for checking Sam.
>>>>
>>>> On Fri, Mar 13, 2015 at 11:00 AM, Sam Ottenhoff <
>>>> ottenhoff at longsight.com> wrote:
>>>>
>>>>> On https://qa10-mysql.nightly.sakaiproject.org with two browsers
>>>>> open, I grant Announcements -> Create to Student role and I instantly have
>>>>> ability to create an announcement as student0011.
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Mar 13, 2015 at 10:54 AM, Matthew Buckett <
>>>>> matthew.buckett at it.ox.ac.uk> wrote:
>>>>>
>>>>>> On 13 March 2015 at 14:47, Earle Nietzel <enietzel at anisakai.com>
>>>>>> wrote:
>>>>>>
>>>>>>> My initial thought,
>>>>>>>
>>>>>>> There was no invalidation on the permission change.
>>>>>>>
>>>>>>
>>>>>>> So you were probably going to wait on a TTL of a cache before it was
>>>>>>> flushed.
>>>>>>>
>>>>>>
>>>>>> Yep, but is that the expected behaviour?
>>>>>>
>>>>>> --
>>>>>>   Matthew Buckett, VLE Developer, IT Services, University of Oxford
>>>>>>
>>>>>> _______________________________________________
>>>>>> sakai-core-team mailing list
>>>>>> sakai-core-team at collab.sakaiproject.org
>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-core-team
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> earle,
>>>> asahi net int.
>>>>
>>>
>>>
>>>
>>> --
>>>   Matthew Buckett, VLE Developer, IT Services, University of Oxford
>>>
>>
>>
>>
>> --
>> earle,
>> asahi net int.
>>
>> _______________________________________________
>> sakai-core-team mailing list
>> sakai-core-team at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-core-team
>>
>>
>


-- 
earle,
asahi net int.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-core-team/attachments/20150316/3a63c849/attachment.html