[
https://issues.apache.org/jira/browse/SLING-13103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-13103:
------------------------------------
Description:
After the Jakarta migration, {{DefaultSlingScript.verifySlingBindings()}} sets
the resolver binding using {{sling.getJakartaRequest().getResourceResolver()}}.
This returns an incorrect ResourceResolver when the script is invoked after a
RequestDispatcher.forward() from a javax.servlet.Filter that wraps the request
with a custom SlingHttpServletRequestWrapper providing a custom
ResourceResolver.
The symptom is that a script receives the original request's ResourceResolver
in its bindings instead of the custom one provided by the forwarding filter's
request wrapper, leading to resource resolution failures.
The problem can be traced in the following way:
During request dispatch,
[SlingRequestDispatcher.dispatch()|https://github.com/apache/sling-org-apache-sling-engine/blob/08e1bdd781be7357ff4132c9a69fc78a181430ea/src/main/java/org/apache/sling/engine/impl/request/SlingRequestDispatcher.java#L156]
calls
[RequestData.unwrap(request)|https://github.com/apache/sling-org-apache-sling-engine/blob/08e1bdd781be7357ff4132c9a69fc78a181430ea/src/main/java/org/apache/sling/engine/impl/request/RequestData.java#L302]
which strips away all servlet request wrappers — including the javax → jakarta
bridge wrappers that contained the custom javax SlingHttpServletRequestWrapper.
After unwrapping, the underlying SlingJakartaHttpServletRequestImpl is exposed,
and its methods diverge:
- getResource() → delegates to requestData.getContentData().getResource() —
returns the dispatched resource (correct, since SlingRequestProcessorImpl
stores it in ContentData during dispatch)
- getResourceResolver() → delegates to requestData.getResourceResolver() —
returns the original request's resolver (incorrect, since
RequestData.resourceResolver is set once during initResource() and never
updated on dispatch)
was:
After the Jakarta migration, {{DefaultSlingScript.verifySlingBindings()}} sets
the resolver binding using {{sling.getJakartaRequest().getResourceResolver()}}.
This returns an incorrect ResourceResolver when the script is invoked after a
RequestDispatcher.forward() from a javax.servlet.Filter that wraps the request
with a custom SlingHttpServletRequestWrapper providing a custom
ResourceResolver.
The symptom is that a script receives the original request's ResourceResolver
in its bindings instead of the custom one provided by the forwarding filter's
request wrapper, leading to resource resolution failures.
The problem can be traced in the following way:
During request dispatch,
[SlingRequestDispatcher.dispatch()|https://github.com/apache/sling-org-apache-sling-engine/blob/08e1bdd781be7357ff4132c9a69fc78a181430ea/src/main/java/org/apache/sling/engine/impl/request/SlingRequestDispatcher.java#L156]
calls
[RequestData.unwrap(request)](https://github.com/apache/sling-org-apache-sling-engine/blob/08e1bdd781be7357ff4132c9a69fc78a181430ea/src/main/java/org/apache/sling/engine/impl/request/RequestData.java#L302)
which strips away all servlet request wrappers — including the javax → jakarta
bridge wrappers that contained the custom javax SlingHttpServletRequestWrapper.
After unwrapping, the underlying SlingJakartaHttpServletRequestImpl is exposed,
and its methods diverge:
- getResource() → delegates to requestData.getContentData().getResource() —
returns the dispatched resource (correct, since SlingRequestProcessorImpl
stores it in ContentData during dispatch)
- getResourceResolver() → delegates to requestData.getResourceResolver() —
returns the original request's resolver (incorrect, since
RequestData.resourceResolver is set once during initResource() and never
updated on dispatch)
> Wrong ResourceResolver set in script bindings after request dispatch in a
> Jakarta Context
> -----------------------------------------------------------------------------------------
>
> Key: SLING-13103
> URL: https://issues.apache.org/jira/browse/SLING-13103
> Project: Sling
> Issue Type: Bug
> Components: Scripting
> Reporter: Robert Munteanu
> Assignee: Robert Munteanu
> Priority: Major
> Fix For: Scripting Core 3.0.2
>
>
> After the Jakarta migration, {{DefaultSlingScript.verifySlingBindings()}}
> sets the resolver binding using
> {{sling.getJakartaRequest().getResourceResolver()}}.
> This returns an incorrect ResourceResolver when the script is invoked after a
> RequestDispatcher.forward() from a javax.servlet.Filter that wraps the
> request with a custom SlingHttpServletRequestWrapper providing a custom
> ResourceResolver.
> The symptom is that a script receives the original request's ResourceResolver
> in its bindings instead of the custom one provided by the forwarding filter's
> request wrapper, leading to resource resolution failures.
> The problem can be traced in the following way:
> During request dispatch,
> [SlingRequestDispatcher.dispatch()|https://github.com/apache/sling-org-apache-sling-engine/blob/08e1bdd781be7357ff4132c9a69fc78a181430ea/src/main/java/org/apache/sling/engine/impl/request/SlingRequestDispatcher.java#L156]
> calls
> [RequestData.unwrap(request)|https://github.com/apache/sling-org-apache-sling-engine/blob/08e1bdd781be7357ff4132c9a69fc78a181430ea/src/main/java/org/apache/sling/engine/impl/request/RequestData.java#L302]
> which strips away all servlet request wrappers — including the javax →
> jakarta bridge wrappers that contained the custom javax
> SlingHttpServletRequestWrapper.
> After unwrapping, the underlying SlingJakartaHttpServletRequestImpl is
> exposed, and its methods diverge:
> - getResource() → delegates to requestData.getContentData().getResource() —
> returns the dispatched resource (correct, since SlingRequestProcessorImpl
> stores it in ContentData during dispatch)
> - getResourceResolver() → delegates to requestData.getResourceResolver() —
> returns the original request's resolver (incorrect, since
> RequestData.resourceResolver is set once during initResource() and never
> updated on dispatch)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
