jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Farhan Nawaz (Jira)" <j...@apache.org>
Subject [jira] [Updated] (OAK-9107) AEM Sites - Impersonated user cannot unlock node, even if it's the lock owner.
Date Tue, 09 Jun 2020 11:58:00 GMT

     [ https://issues.apache.org/jira/browse/OAK-9107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Farhan Nawaz updated OAK-9107:
------------------------------
    Description: 
Use Case - Creating version of a node, that is itself locked or has locked descendant nodes.

Impersonated user doesn’t have support for relaxed locking and hence version checkout operation
fails. 

Possible Solutions :

*OAK provides support for relaxed locking with impersonated user* - This would be the preferred
choice for us. This would make relaxed locking consistent across user logged-in sessions and
impersonated sessions (sync v async).

*Using 'unlock-with-lock-token' approach in AEM* - Technically it's possible to do this, but
we have the following concerns related to this approach :
 # This approach requires all such lock tokens to be acquired at the time of session creation
and then adding them to the session scope. It's not feasible to have this information available
beforehand all the time, and as such is prone to failures.
 # We might need to do traversals from the root node onwards, to find all such locked nodes
and then recover lock tokens. Lock management is pretty low level handling, and exposing this
much dependency on the application side would be a risk.
 # For Customers with heavy content packages and thousands of references, traversals for recovery
of lock tokens would add additional load on the system and could negatively impact performance. 

Overall we feel that the long term solution to this, would be to add the support for relaxed
locking with impersonated sessions. 

 

  was:
Use Case - Creating version of a node, that is itself locked or has locked descendant nodes.

Impersonating user doesn’t have support for relaxed locking and hence version checkout operation
fails. 

Possible Solutions :

*OAK provides support for relaxed locking with impersonated user* - This would be the preferred
choice for us. This would make relaxed locking consistent across user logged-in sessions and
impersonated sessions (sync v async).

*Using 'unlock-with-lock-token' approach in AEM* - Technically it's possible to do this, but
we have the following concerns related to this approach :
 # This approach requires all such lock tokens to be acquired at the time of session creation
and then adding them to the session scope. It's not feasible to have this information available
beforehand all the time, and as such is prone to failures.
 # We might need to do traversals from the root node onwards, to find all such locked nodes
and then recover lock tokens. Lock management is pretty low level handling, and exposing this
much dependency on the application side would be a risk.
 # For Customers with heavy content packages and thousands of references, traversals for recovery
of lock tokens would add additional load on the system and could negatively impact performance. 

Overall we feel that the long term solution to this, would be to add the support for relaxed
locking with impersonated sessions. 

 


> AEM Sites - Impersonated user cannot unlock node, even if it's the lock owner.
> ------------------------------------------------------------------------------
>
>                 Key: OAK-9107
>                 URL: https://issues.apache.org/jira/browse/OAK-9107
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: jcr
>            Reporter: Farhan Nawaz
>            Priority: Major
>
> Use Case - Creating version of a node, that is itself locked or has locked descendant
nodes.
> Impersonated user doesn’t have support for relaxed locking and hence version checkout
operation fails. 
> Possible Solutions :
> *OAK provides support for relaxed locking with impersonated user* - This would be the
preferred choice for us. This would make relaxed locking consistent across user logged-in
sessions and impersonated sessions (sync v async).
> *Using 'unlock-with-lock-token' approach in AEM* - Technically it's possible to do this,
but we have the following concerns related to this approach :
>  # This approach requires all such lock tokens to be acquired at the time of session
creation and then adding them to the session scope. It's not feasible to have this information
available beforehand all the time, and as such is prone to failures.
>  # We might need to do traversals from the root node onwards, to find all such locked
nodes and then recover lock tokens. Lock management is pretty low level handling, and exposing
this much dependency on the application side would be a risk.
>  # For Customers with heavy content packages and thousands of references, traversals
for recovery of lock tokens would add additional load on the system and could negatively impact
performance. 
> Overall we feel that the long term solution to this, would be to add the support for
relaxed locking with impersonated sessions. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message