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

Jukka Zitting commented on JCR-3208:
------------------------------------

> admin to unlock

Explicit admin intervention is already taking the repository outside the scope 
of normal JCR semantics, so I wouldn't be too worried about this case.

A similar case could arise if in step 2 user A explicitly hands over the lock 
token to user B, but in that case I'd assume the users to be aware of each 
others actions and synchronize accordingly.

So while it might be useful to do this (and it looks like this could be 
achieved in a backwards-compatible manner), I'm not sure how pressing the issue 
is. If there's an itch to fix this, +1 to proceed.

PS. The one thing that could be a pretty reason to do this is that with the 
lock token based directly on the UUID of the node, anyone with sufficient read 
access to a node can calculate the token of an open-scoped lock and thus unlock 
the node without interaction with an administrator or the original lock holder. 
That could be a security and/or consistency issue in some circumstances.

                
> locking a node twice yields the same lock token
> -----------------------------------------------
>
>                 Key: JCR-3208
>                 URL: https://issues.apache.org/jira/browse/JCR-3208
>             Project: Jackrabbit Content Repository
>          Issue Type: Task
>          Components: jackrabbit-core, locks
>            Reporter: Julian Reschke
>            Priority: Minor
>
> Due to the way jackrabbit assigns lock tokens, the same lock token is 
> generated every time a node is locked.
> This seems to contradict a JCR requirement:
> "A lock token is a string that uniquely identifies a particular lock and acts 
> as a key granting lock ownership to any session that hold the token." 
> <http://www.day.com/specs/jcr/2.0/17_Locking.html#17.5%20Lock%20Token>
> ...in that two subsequent locks on the same node get the same token.
> (This may be harmless but we should consider fixing this for compliance 
> reasons)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to