You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Andreas Schaefer Sr." <sc...@me.com> on 2017/02/09 21:19:03 UTC

Sling is disregarding changes in filters

Hi

I am working at a project (AEM 6.2) where the customer is used Portlets.

These are legacy portlets and have very long query strings. The previous
deployment used some features of the web server that hide that query string.

In AEM 6.0 I created a link rewriter / filter that took the query string, placed it
into the session and returned a query string with a reference to the session cache.
On the returning call (action / render) the query string was the re-applied to the
Servlet Request by wrapping the request and returning the new / old query string.

Now In AEM 6.2 that fails and I figured out that:

1) The ParameterSupport class is obtaining the values from the request in this method:

private ParameterMap getRequestParameterMapInternal() {
    if (this.postParameterMap == null) {

(line 221 in org.apache.sling.engine 2.4.6)

2) AEM 6.2 does obtain the first parameter from the request on the HTTPAuthHandler.forceAuthentication()
and therefore fixes all the variables. This handler is called way before my filter and so any changes made
by this filter is disregarded.

I could circumvent that by intercepting the request for the “org.apache.sling.engine.impl.parameters.ParameterSupport”
attribute with which I was finally able to call the portlet.

From what I see the code is fine but the method:

public static ParameterSupport getInstance(HttpServletRequest request) {
    Object instance = request.getAttribute(ATTR_NAME);
    if (!(instance instanceof ParameterSupport)) {
        instance = new ParameterSupport(request);
        request.setAttribute(ATTR_NAME, instance);
    }
    return (ParameterSupport) instance;
}

Should also check if the Parameter Support instance is based off the same request and recreated it. Something like
this:

public static ParameterSupport getInstance(HttpServletRequest request) {
    Object instance = request.getAttribute(ATTR_NAME);
    if (!(instance instanceof ParameterSupport)) {
        instance = new ParameterSupport(request);
        request.setAttribute(ATTR_NAME, instance);
    } else {
        ParameterSupport found = (ParameterSupport) instance;
        if(request != found.getServletRequest) {
            instance = new ParameterSupport(request);
            request.setAttribute(ATTR_NAME, instance);
    }
    return (ParameterSupport) instance;
}

Cheers - Andy Schaefer


Re: Sling is disregarding changes in filters

Posted by Robert Munteanu <ro...@apache.org>.
Hi Andy,

On Thu, 2017-02-09 at 13:19 -0800, Andreas Schaefer Sr. wrote:
> Hi
> 
> I am working at a project (AEM 6.2) where the customer is used
> Portlets.
> 
> These are legacy portlets and have very long query strings. The
> previous
> deployment used some features of the web server that hide that query
> string.
> 
> In AEM 6.0 I created a link rewriter / filter that took the query
> string, placed it
> into the session and returned a query string with a reference to the
> session cache.
> On the returning call (action / render) the query string was the re-
> applied to the
> Servlet Request by wrapping the request and returning the new / old
> query string.
> 
> Now In AEM 6.2 that fails and I figured out that:
> 
> 1) The ParameterSupport class is obtaining the values from the
> request in this method:
> 
> private ParameterMap getRequestParameterMapInternal() {
> ����if (this.postParameterMap == null) {
> 
> (line 221 in org.apache.sling.engine 2.4.6)
> 
> 2) AEM 6.2 does obtain the first parameter from the request on the
> HTTPAuthHandler.forceAuthentication()
> and therefore fixes all the variables. This handler is called way
> before my filter and so any changes made
> by this filter is disregarded.
> 
> I could circumvent that by intercepting the request for the
> \u201corg.apache.sling.engine.impl.parameters.ParameterSupport\u201d
> attribute with which I was finally able to call the portlet.
> 
> From what I see the code is fine but the method:
> 
> public static ParameterSupport getInstance(HttpServletRequest
> request) {
> ����Object instance = request.getAttribute(ATTR_NAME);
> ����if (!(instance instanceof ParameterSupport)) {
> ��������instance = new ParameterSupport(request);
> ��������request.setAttribute(ATTR_NAME, instance);
> ����}
> ����return (ParameterSupport) instance;
> }
> 
> Should also check if the Parameter Support instance is based off the
> same request and recreated it. Something like
> this:
> 
> public static ParameterSupport getInstance(HttpServletRequest
> request) {
> ����Object instance = request.getAttribute(ATTR_NAME);
> ����if (!(instance instanceof ParameterSupport)) {
> ��������instance = new ParameterSupport(request);
> ��������request.setAttribute(ATTR_NAME, instance);
> ����} else {
> ��������ParameterSupport found = (ParameterSupport) instance;
> ��������if(request != found.getServletRequest) {
> ������������instance = new ParameterSupport(request);
> ������������request.setAttribute(ATTR_NAME, instance);
> ����}
> ����return (ParameterSupport) instance;
> }

Not sure if this issue as the same one as your email with the subject
"Parameter Support, Filters and Missing Paramaters" [1], but my advice
still is to create an issue with a failing test.

Thanks,

Robert

[1]: https://lists.apache.org/thread.html/5cc172ebd140323a94494e03e5a91
2f695c27a4759e950ca7ca354d3@%3Cdev.sling.apache.org%3E