jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lukas Eder <lukas.e...@gmail.com>
Subject Re: "Secure realm" of internal APIs to prevent costly access control lookups
Date Tue, 26 Mar 2013 11:01:13 GMT
Hello Angela,

2013/3/26 Angela Schreiber <anchela@adobe.com>:
> hi lukas
> (moving discussion back to the regular jackrabbit dev list)

Thanks, you're right. Further discussions might be off-topic for oak.

>>> 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.
> that's is not correct.
> i don't know what you are doing but solely configuring the
> custom ac provider in the workspace configuration should be
> sufficient to get the setup right...

I may have been mixing up the various actors that are involved in
access control lookups. Ultimately, however,
AccessControlProvider.compilePermissions() is called, regardless if in
the context of a system/admin session or a regular one. A sample
implementation from the Jackrabbit core:

    public CompiledPermissions compilePermissions(Set<Principal>
principals) throws RepositoryException {
        if (isAdminOrSystem(principals)) {
            return getAdminPermissions();
        } else if (isReadOnly(principals)) {
            return getReadOnlyPermissions();
        } else {
            return new CompiledPermissionsImpl(principals, session,
entryCollector, this, true);

This is what I mean by saying that the relevant bypass for
system/admin sessions is implemented explicitly in
AccessControlProvider implementations.

And it is easy to see how I can get it wrong, if I don't re-implement
the above in my own implementation :-)

> please note that the ac provider interface is *not* part
> of the public jackrabbit API but an internal interface which
> is not meant to be accessed by JCR API consumers.

I know. But my current requirements are quite complex, and as you
remember from our discussion, the ideal way to implement the
additional access control mechanisms is by using Jackrabbit's


View raw message