Hi Angela,
> in contrast to jr-core access control mgt and permission evaluation
> will not be built on top of the JCR stack but be located below the
> new "SPI" boundary inside oak-core.
So, in essence, there are means of accessing the OAK-internal
repository representation through this SPI explicitly. It will be
low-level, but it will allow for bypassing access control. That's what
you're saying?
> consequently we no longer have the need for (shared) system session.
> btw: in jackrabbit-core system sessions already bypasses all kind
> of access control evaluation.
That's what I would've expected. However, this bypass is implemented
explicitly in AccessControlProvider implementations. I had missed this
fact at first, when I was implementing my own.
Regards,
Lukas
>
> kind regards
> angela
>
>
> On 3/25/13 4:09 PM, Lukas Eder wrote:
>>
>> Hello,
>>
>> I'm currently looking into extending Jackrabbit's (not OAK's) access
>> control management, and I found it easy to see how this area is a
>> significant performance bottleneck for today's Jackrabbit Content
>> Repository.
>>
>> The biggest design and architecture problem, in my opinion, is the
>> need for a session with associated, hard-coded access control
>> behaviour. From what I understand so far, there are (possibly
>> non-exhaustive):
>>
>> - System sessions
>> - Admin sessions
>> - User sessions
>>
>> In my opinion, in OAK, there should be something like a "secure
>> realm". Once this realm is entered, executing code should get complete
>> access to all of the repository through standard internal and external
>> API. For example, such behaviour could be achieved through setting a
>> ThreadLocal "monitor" in a local execution context as such:
>>
>> // Outside of the "secure realm". JCR access goes through access
>> control
>> T result = secure(new Securable<T>() {
>> public T run() {
>> // Inside of the "secure realm". JCR access
>> // would now bypass access control
>> }
>> });
>>
>> And this could be the implementation of secure():
>>
>> private static final ThreadLocal<Boolean> t = new
>> ThreadLocal<Boolean>();
>>
>> // OAK internals could use this to check if access control is needed
>> public static boolean isSecured() {
>> return t.get() != null;
>> }
>>
>> public static<T> T secure(Securable<T> s) {
>> // Already secured
>> if (isSecured()) {
>> return s.run();
>> }
>> else {
>> try {
>> t.set(true);
>> return s.run();
>> }
>> finally {
>> t.remove();
>> }
>> }
>> }
>>
>> Such use of ThreadLocal is smelly and potentially slow, of course.
>> This is just to illustrate the idea. More realistic use-cases would
>> probably expose a shareable system session within the "secure realm".
>> The important thing is that this system session would also bypass
>> access control.
>>
>> Are there any such plans in OAK?
>>
>> Cheers
>> Lukas
