jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Tuckett <nick.tuck...@playfish.com>
Subject Re: Access Control problem when reading back node saved inside an XA Transaction
Date Thu, 27 Sep 2012 15:32:29 GMT
I have been able to narrow this down further, and have a test case for it
(attached, can be dropped in to org.apache.jackrabbit.core.integration to
be run).

The key seems to be to have an unsaved change on the new node which is
being retrieved. This means the node's item state is
ItemState.STATUS_EXISTING_MODIFIED, which causes ItemManager.canRead() to
check with the access manager for read permission - leading to the
exception described below.

If there is no unsaved change on the new node, its state is
ItemState.STATUS_NEW, which makes ItemManager.canRead() return true
(default assumption for new nodes added by client code).

I think I can now fix my original problem that showed this (there's an
unsaved session change that can be saved) - however could this be a more
general problem that ought to be addressed?

On 27 September 2012 12:07, Nick Tuckett <nick.tuckett@playfish.com> wrote:

> Hi
>
> I'm working with Jackrabbit 2.4.2 and have the following scenario:
>
>    - Create a session for a non-admin user account.
>    - Cast the session to an XAResource, generate a new transaction ID and
>    start a transaction (like org.apache.jackrabbit.core.UserTransactionImpl).
>    - Use the session to create a new node, record its identifier then set
>    some properties and save the session.
>    - After some further processing logic not using Jackrabbit, attempt to
>    get the new node via its identifier.
>       - javax.jcr.ItemNotFoundException is thrown from
>       inside org.apache.jackrabbit.core.security.authorization.acl.CompiledPermissionsImpl.canRead
>       when it uses an ItemManager instance to get the new node.
>
> I have debugged through my code and the Jackrabbit code it calls, and can
> see the following:
>
>    - My new node is present in the item cache for my session, which is
>    retrieved ok by the getNodeByIdentifier() call.
>    - The permissions check above tries to retrieve my node by id using a
>    different (system) session in the DefaultAccessManager, which doesn't have
>    my node in its cache. This attempts to read the node from the persistence
>    layer as a result, which fails as the data won't be there because of the
>    transaction.
>
> If I perform the same operation with an admin account, it works fine as
> the can-read check is short-circuited to always return true.
>
> Is there something I'm missing in how access control should be configured,
> or how I'm using transactions?
>
> Thanks in advance,
>
> Regards
>
> Nick Tuckett.
>
>
>

Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message