Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
1.0
-
None
Description
as discussed during our biweekly planning session, we are having the following locking related use case in our product:
a page (which is an aggregation of nodes and properties) must be freezed (prevented from being edited/modified/deleted) during the period of a dedicated review (which in our case is triggered by a workflow) before the page then is either published or reopened for further changes.
for this feature locking would be a perfect match but with the current implementation in oak it's not possible to remove the lock token from a given session and make sure it's no longer recognizes as lock owner; in particular with the simple-locking feature which we introduced in order to cope with the situation that in our product sessions are living just for the time of a single request.
is was therefore thinking about ways to address this, keeping the simple-locking requirement in mind while at the same time improving compliance with the JCR specification. my suggestion as follows:
- use a dedicated hidden and write protected location the repository to store the lock information independent of the protected properties defined by mix:lockable which are just for information purpose (that would be the replacement for the lock-related file we had in jackrabbit 2.x)
- format: simple lookup consisting of userId + associated lock tokens
- in case of simple locking LockManager#getLockTokens would make use of that map even if the lock tokens have NOT been explicitly added to the Session either upon LockManager#lock or LockManager#addLockToken
- in the default (non-simple case) LockManager#getLockTokens would work as specified and the lookup would only be used for maintaining and enforcing the lock related information)
- LockManager#removeLockToken removes the token from the lookup thus effectively revoking the lock ownership from the given Session and thus preventing it from performing further editing... even in the simple-locking case
- LockManager#addLockToken results in a modification of the lookup table as well depending on the API contract (i.e. verifying if the lock token would be shared... i don't remember exactly if that's accepted by the specification)
- LockManager#isLockOwner no longer needs to perform a cheap hack comparing the jcr:lockOwner property with the sessions userId but could really enforce ownership based on the internal lock information stored in the repository in which case getLockTokens would really reflect the ownership for open-scoped locks; furthermore the 'jcr:lockOwner' information could be to what is specified by the API consumer upon LockManager#lock as it is no longer used for enforcing the locks.
in addition:
- we could generated proper lock tokens instead of just using the node id
and again keep those in a hidden (or otherwise protected) location in the system.
Attachments
Issue Links
1.
|
Content can be changed by users who do not own the lock |
|
Resolved | Unassigned |
2.
|
Locks are not enforced for content changes |
|
Resolved | Unassigned |
3.
|
Admin cannot create versions on a locked page by itself |
|
Closed | Marcel Reutegger |
4.
|
oak-jcr: update test exclusions once JCR-3900 is resolved |
|
Closed | Julian Reschke |
5.
|
consider existing locks when creating new ones |
|
Closed | Julian Reschke |
6.
|
oak-jcr: update test exclusions once JCR-3901 is resolved |
|
Closed | Julian Reschke |
7.
|
Lock object spec compliance issue |
|
Resolved | Unassigned |
8.
|
NodeDelegate: checking for locks should not require read access to system lock properties |
|
Resolved | Unassigned |
9.
|
LockImpl.isLockOwningSession not consistent with unlock-capability |
|
Open | Unassigned |
10.
|
Duplicate and case sensitive comparison of lockowner with user id |
|
Open | Unassigned |
11.
|
Bogus lock token |
|
Resolved | Unassigned |