Libclient caching does not respect accessPolicies
Currently, libclient allows the get() method to specify the session/subject of the caller, but the underlying JCS cache does not associate the session/subject of the caller with the cache. Therefore, objects retrieved by one subject are available to any other subject using that MNode instance, even if otherwise a NotAuthorized would be returned if the object was not previously cached.
#2 Updated by Rob Nahf about 11 years ago
- translation missing: en.field_remaining_hours set to 0.0
- Due date set to 2012-10-27
- Priority changed from High to Low
- Target version changed from Sprint-2012.39-Block.5.4 to Sprint-2012.41-Block.6.1
this is not a burning issue, so find an easy solution or throw into the backlogs.
#5 Updated by Rob Nahf over 10 years ago
possible solutions are multiple caches (one per subject), local access policy checking, perform a describe request, or isAuthorized() prior to returning from the cache (if cached), clearing the cache for new subjects, associating the cached object with a subject.
the describe check is probably the most elegant, but does introduce http connection overhead compared to not doing any checks at all. The other options require introspection of the subject for each call, and could lead to unnecessary downloads.
Another approach is a multi-client caching configuration option that would only implement access policy checks when configured that way.