[jira] [Resolved] (SLING-6559) Sling is hiding / ignoring Parameter / Query String changes from Filters ahead of Sling

["Carsten Ziegeler (Jira)" <ji...@apache.org>]

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

Carsten Ziegeler resolved SLING-6559.
-------------------------------------
    Resolution: Won't Fix

> Sling is hiding / ignoring Parameter / Query String changes from Filters ahead of Sling
> ---------------------------------------------------------------------------------------
>
>                 Key: SLING-6559
>                 URL: https://issues.apache.org/jira/browse/SLING-6559
>             Project: Sling
>          Issue Type: Bug
>          Components: Engine
>         Environment: Sling 9, JDK 1.8
>            Reporter: Andreas Schaefer
>            Priority: Major
>              Labels: FIlter, HttpServletRequest, Parameter
>         Attachments: ticket-sling-parameter-problem-example.zip
>
>
> Any changes to parameters or the query string in a Servlet Filter ahead of Sling (before Sling Main Servlet) are ignore in Sling due to the usage of the Parameter Support class.
> This means that any such filter will not receive the parameters in the request, cannot wrap the request and add, change or delete them and cannot change the query string.
> I attached a sample project that will showcase that (see the ReadMe.markdown) file in the root folder. The project can be built with **mvn clean install** and if Composum is installed and whitelisted you can auto deploy it with (mvn clean install -P auto-deploy-all.
> I know this is an edge case but I had at least two clients in the last two years
> that required to change parmaeters and / or query strings before the Sling resource
> is resolved.
> But even without that Sling based on javax.servlet specification should adhere to
> that and with it support and respect filters and their changes.
> The reason why this goes wrong is that the Parameter Support is created during the
> authentication phase way ahead of "regular" filters and with it the parameters
> are fixed into place.
> For a client I created a fixe by intercepting the getAttribute() for the Parameter
> Support attribute and return null to create a new Parameter Support instance. To
> make this work I had to read out all parameters from the original Parameter Support
> instance to carry them over as well as set the flag for additional parameters.
> This is working in AEM 6.2 SP1 but this is for sure not a good and generic solution.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)