[
https://issues.apache.org/jira/browse/OAK-9224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17200785#comment-17200785
]
Tomek Rękawek edited comment on OAK-9224 at 9/23/20, 12:13 PM:
---------------------------------------------------------------
[~angela], ok, so the context and the use case to import tokens is as follows:
I have a bunch of Oak instances, with separate repositories (no cluster). I'm
trying to create an user synchronization mechanism between them, based on the
JCR XML serialization. When an user or a group is modified on a single
instance, it's being serialized to XML and transmitted to all the other
instances, where it's being desynchronized and applied.
Now, if I'm logging in as {{tomek}} and I'm modyfing my user profile, it'll be
distributed to all the other instances. However, they won't be able to
desynchronize them because of the exception as above.
If we ignore the properties, the import will work, but the {{.tokens}} will be
purged on all the receiver Oak instances for the particular user. This may
result in logging out the users signed in there, assuming the same user is
signed in with 2 different browsers.
Having the {{.tokens}} synchronized would have one extra benefit in my use
case. All these Oak instances are exposed to web traffic via load balancer,
with sticky sessions enabled. However, if one of the instances is shut down,
the user will be redirected to another one by the load balancer. If the user's
token is already there, they won't be forced to login again.
was (Author: tomek.rekawek):
Ok, so the context and the use case to import tokens is as follows:
I have a bunch of Oak instances, with separate repositories (no cluster). I'm
trying to create an user synchronization mechanism between them, based on the
JCR XML serialization. When an user or a group is modified on a single
instance, it's being serialized to XML and transmitted to all the other
instances, where it's being desynchronized and applied.
Now, if I'm logging in as {{tomek}} and I'm modyfing my user profile, it'll be
distributed to all the other instances. However, they won't be able to
desynchronize them because of the exception as above.
If we ignore the properties, the import will work, but the {{.tokens}} will be
purged on all the receiver Oak instances for the particular user. This may
result in logging out the users signed in there, assuming the same user is
signed in with 2 different browsers.
Having the {{.tokens}} synchronized would have one extra benefit in my use
case. All these Oak instances are exposed to web traffic via load balancer,
with sticky sessions enabled. However, if one of the instances is shut down,
the user will be redirected to another one by the load balancer. If the user's
token is already there, they won't be forced to login again.
> Create a protected property importer for handling user tokens
> -------------------------------------------------------------
>
> Key: OAK-9224
> URL: https://issues.apache.org/jira/browse/OAK-9224
> Project: Jackrabbit Oak
> Issue Type: Story
> Components: core, security
> Reporter: Tomek Rękawek
> Assignee: Tomek Rękawek
> Priority: Major
> Fix For: 1.36.0
>
>
> An attempt to invoke {{javax.jcr.Session#importXML()}} on a payload including
> exported {{rep:User}} nodes will fail with the following message if the
> {{.tokens}} subnode is not empty:
> {noformat}
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0021:
> /home/users/5/5d60zjEABcbAjvqo8SyI/.tokens/50c611f9-9886-4124-ada6-e224ffeead8e[[rep:Token]]:
> Mandatory property rep:token.key not found in a new node
> at
> org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:226)
> [org.apache.jackrabbit.oak-api:1.34.0]
> at
> org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:213)
> [org.apache.jackrabbit.oak-api:1.34.0]
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.newRepositoryException(SessionDelegate.java:677)
> [org.apache.jackrabbit.oak-jcr:1.34.0]
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:503)
> [org.apache.jackrabbit.oak-jcr:1.34.0]
> at
> org.apache.jackrabbit.oak.jcr.session.SessionImpl$8.performVoid(SessionImpl.java:424)
> [org.apache.jackrabbit.oak-jcr:1.34.0]
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:273)
> [org.apache.jackrabbit.oak-jcr:1.34.0]
> at
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.save(SessionImpl.java:421)
> [org.apache.jackrabbit.oak-jcr:1.34.0]
> at
> com.adobe.granite.repository.impl.CRX3SessionImpl.save(CRX3SessionImpl.java:207)
> [com.adobe.granite.repository:1.6.100]
> {noformat}
> The reason is that all the properties in rep:Token nodes are protected:
> {noformat}
> [rep:Token] > mix:referenceable
> - rep:token.key (string) mandatory protected
> - rep:token.exp (date) mandatory protected
> - * (undefined) protected
> - * (undefined) protected multiple
> {noformat}
> and they'll be skipped by the importer unless there's a custom
> ProtectedPropertyImporter implementation handling them:
> https://github.com/apache/jackrabbit-oak/blob/bb749cac90617f9350189599f5f63ec20da7c490/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/xml/ImporterImpl.java#L278-L288
> The goal of this story is to create such implementation, so the tokens can be
> imported together with the rest of the {{rep:User}} subtree.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
