Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <1597324463.1225790444389.JavaMail.jira@brutus>
Date: Tue, 4 Nov 2008 01:20:44 -0800 (PST)
From: "angela (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Issue Comment Edited: (JCR-643) Own AccessManager +
 VersionManager : AccesDenied problem
In-Reply-To: <25681206.1164296222040.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/JCR-643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12644256#action_12644256 ] 

anchela edited comment on JCR-643 at 11/4/08 1:20 AM:
-----------------------------------------------------

> Can I use versioning with own AccessManager? 

i made some tests combining operations that affect version-related items and/or the
version storage with limited permissions on those items.

my findings:

- limited READ access to version related items be it in the version storage or
  within the 'normal' content works as expected.

- limited WRITE permission within the version-storage is not respected at all.

- limited WRITE permission with version related protected properties such as 
  e.g. jcr:isCheckedOut is respected but upon AccessDeniedException the item modifications
  are not reverted as expected.
  example: if Node.checkin() fails due to missing write permission the jcr:isCheckedOut
  property is transiently modified and it's value is false, which is wrong from my point of
  view. (see also JCR-538)

possible solutions include:

- reverting transient modifications upon failure of workspace operations (not only
  version operations)
- introduce special handling of protected properties upon Item.save()
- introduce special privileges for those API methods that affect protected item that
  can be checked before executing the methods.

the latter is something that is discussed within the scope of JSR 283.

regarding your problem:

- you need to add READ permission to the version storage not only  the versionable item.
  the behavior you describe seems to be the expected outcome.


      was (Author: anchela):
    > Can I use versioning with own AccessManager? 

i made some tests combining operations that affect version-related items and/or the
version storage with limited permissions on those items.

my findings:

- limited READ access to version related items be it in the version storage or
  within the 'normal' content works as expected.

- limited WRITE permission within the version-storage is not respected at all.

- limited WRITE permission with version related protected properties such as 
  e.g. jcr:isCheckedOut is respected but upon AccessDeniedException the item modifications
  are not reverted as expected.
  example: if Node.checkin() fails due to missing write permission the jcr:isCheckedOut
  property is transiently modified and it's value is false, which is wrong from my point of
  view.

possible solutions include:

- reverting transient modifications upon failure of workspace operations (not only
  version operations)
- introduce special handling of protected properties upon Item.save()
- introduce special privileges for those API methods that affect protected item that
  can be checked before executing the methods.

the latter is something that is discussed within the scope of JSR 283.

regarding your problem:

- you need to add READ permission to the version storage not only  the versionable item.
  the behavior you describe seems to be the expected outcome.


> Own AccessManager + VersionManager : AccesDenied problem
> --------------------------------------------------------
>
>                 Key: JCR-643
>                 URL: https://issues.apache.org/jira/browse/JCR-643
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: jackrabbit-core, versioning
>    Affects Versions: 1.4, 1.5.0
>            Reporter: Andrey
>         Attachments: VersionStorageAccessTest.java
>
>
> I have implemented my own AccessManager, and everything works fine, until I want to use versioning (mix:versionable). 
> When I try this code:
> Node root = session.getRootNode();
> if (root.canAddMixin("mix:referenceable")) root.addMixin("mix:referenceable");
> Node new_node = root.addNode("some_name");
> if (new_node.canAddMixin("mix:referenceable")) new_node.addMixin("mix:referenceable");
> if (new_node.canAddMixin("mix:versionable")) new_node.addMixin("mix:versionable");
> // here I grant privileges to new_node
> handler.addACL(root.getUUID(), new_node.getUUID());
> session.save();
> I have a AccessDeniedException, then I look at jackrabbit sources (VersionManagerImpl.java) and found this:
>  public VersionHistory createVersionHistory(Session session, final NodeState node)
>             throws RepositoryException {
>         InternalVersionHistory history = (InternalVersionHistory)
>                 escFactory.doSourced((SessionImpl) session, new SourcedTarget(){
>             public Object run() throws RepositoryException {
>                 return createVersionHistory(node);
>             }
>         });
> // HERE IS new version node created
>         if (history == null) {
>             throw new VersionException("History already exists for node " + node.getNodeId());
>         }
> // AND HERE you want to check privileges for newly created node
>         return (VersionHistory) ((SessionImpl) session).getNodeById(history.getId());
> }
> // so, SessionImpl ask ItemManager for  NodeImpl, 
> // ItemManager ask  AccessManager about Item privileges ( session.getAccessManager().isGranted(id, AccessManager.READ) ),
> // and my AccessManager don't know anything about this Item, so it (Item) haven't any privileges, 
> // and I have a AccessDeniedException
> Did I miss something? Can I use versioning with own AccessManager?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.