[
https://issues.apache.org/jira/browse/SLING-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16458499#comment-16458499
]
Csaba Varga commented on SLING-3524:
------------------------------------
Here are my pull requests for the proposed fix:
[https://github.com/apache/sling-org-apache-sling-jcr-resource/pull/3]
[https://github.com/apache/sling-org-apache-sling-api/pull/3]
[https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/6]
I'm not sure if this is the right approach to the problem, but it seemed the
simplest.
The idea is to introduce a new key to the authentication info map, to indicate
that the login is happening because of a clone() call. Resource providers can
then adjust their behavior based on the presence of this key. The JCR resource
provider checks the presence of this flag, in addition to the presence of an
explicitly provided JCR session in the login info. If both are present, the
session is cloned using the self-impersonation trick to make sure it's not
shared with the originating resolver.
To allow proper behavior for clones of clones, the JCR resource provider also
updates the authentication info with the cloned session. I'm not sure how
"clean" this approach is, since the API doesn't say whether mutation of the
authentication info is supported as part of a provider login. It works with the
current implementation, but it may still violate the spirit of the API.
> ResourceResolver.clone(null) should not share the same JCR session
> ------------------------------------------------------------------
>
> Key: SLING-3524
> URL: https://issues.apache.org/jira/browse/SLING-3524
> Project: Sling
> Issue Type: Improvement
> Components: JCR, ResourceResolver
> Affects Versions: Resource Resolver 1.0.6
> Reporter: Alexander Klimetschek
> Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {{ResourceResolver.clone()}} will reuse the same JCR session in case it was
> created by passing an existing session using
> {{JcrResourceConstants.AUTHENTICATION_INFO_SESSION}}. If you need a clone of
> the resource resolver to pass into a new, separate thread, and use
> {{ResourceResolver.clone(null)}}, you will actually share the session, but
> this is not obvious. The problem is that a JCR session cannot be shared
> across threads.
> The javadocs of clone() say "the same credential data is used as was used to
> create this instance".
> There are a few problems with this:
> - seeing the session object itself as "credential data" is unintuitive
> - in my code, I have no idea what the original credential data was, so I
> don't know what kind of credential data it was to make the right decision
> - since sharing a JCR session is to be avoided at all times, the resource
> resolver should prevent one from this
> A solution would be if a plain {{ResourceResolver.clone(null)}} would return
> a session that impersonated itself, abstracting this from the resource
> resolver user. Additionally, it might be worth looking that clone always
> returns a new session, unless specifically stated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
