Details
-
Technical task
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
the current lock implementation in oak-jcr contains multiple places where the user id stored with the editing session is compared to lock specific information (lock owner information).
IMO that should be streamlined to make sure the code works consistent across the various methods (which it currently doesn't see OAK-4458).
also it looks troublesome to me that the comparison is case sensitive as the login by default is not case sensitive... alternatively compare it to a value that is known to be immutable such as e.g. the user ID as stored in the user management (and only fall back to session id, which might be null btw) if no user exists or user management is not supported.
in general i find it quite problematic to base any kind of verification based on the jcr:lockOwner implementation, which is NOT intended to be used for that purpose (see specification)... if the locking feature was properly implemented, we would not base the ability to unlock a given node based on information that can be application supplied such as the jcr:lockOwner property but rather make sure we have internal ways that allows for proper verification.