Bug #3165: Libclient caching does not respect accessPolicies - Java Client - DataONE Tasks

Bug #3165

Libclient caching does not respect accessPolicies

Added by Rob Nahf about 12 years ago. Updated almost 10 years ago.

Status:

New

Priority:

Low

Assignee:

Rob Nahf

Category:

d1_libclient_java

Target version:

Start date:

Due date:

% Done:

Story Points:

Sprint:

Description

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.

History

#1 Updated by Rob Nahf about 12 years ago

Target version changed from Sprint-2012.35-Block.5.2 to Sprint-2012.39-Block.5.4
Position changed from 1 to 493
Position set to 1

#2 Updated by Rob Nahf about 12 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.

#3 Updated by Rob Nahf about 12 years ago

Due date changed from 2012-10-27 to 2012-11-10
Target version changed from Sprint-2012.41-Block.6.1 to Sprint-2012.44-Block.6.2

#4 Updated by Rob Nahf almost 12 years ago

Start date deleted (~~2012-08-31~~)
Due date deleted (~~2012-11-10~~)
Target version deleted (~~Sprint-2012.44-Block.6.2~~)

#5 Updated by Rob Nahf over 11 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.