Passing original request object in chain filter in Sling filter | Community
Skip to main content
S
swathiv54399501
Level 3
November 15, 2018
Solved

Passing original request object in chain filter in Sling filter

  • November 15, 2018
  • 5 replies
  • 2071 views

Hi,

We have one sling filter performing some business logic and this is chain filter. But in the logic, we are processing Iterator Object from request attributes. And the same iterator is getting used in next level of chain.

When we try to parse the Iterator in next level we are getting error"Parameter not available" as we have already pasrsed the Iterator Object.

If there any way to pass the original request object in the chain from first filter?

Thanks,

Swati

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
    Best answer by joerghoh

    What iterator from the request are you processing?

    (I know that there is an issue when dealing with multi-part POST requiests. If you have functionality which first casts the SlingHttpServletRequest to a HttpServletRequest and reads it using this API, all subsequent calls to read the body will fail, because the input stream has already been consumed. The Sling implementation consumes it already and provides dedicated methods to access it. We came across this a year or two ago, so I don't know the details anymore.)

    5 replies

    arunpatidar
    Community Advisor
    arunpatidarCommunity Advisor
    Community Advisor
    November 15, 2018

    Hi,

    Can you try like below:

    chain.doFilter(request, response);

    chain.doFilter(request, slingResponse);

    Apache Sling :: Servlet Filter Support

    Arun Patidar
    S
    swathiv54399501Author
    Level 3
    November 15, 2018

    Hi Arun,

    You suggesting to call doFilter twice?

    I noticed the actual problem is reading the attribute twice. When I read the request attribute in filter and again in next level when actual logic is using the same parameter then it is not available and the actual functionality is breaking.

    Thanks,

    Swati

    arunpatidar
    Community Advisor
    arunpatidarCommunity Advisor
    Community Advisor
    November 15, 2018

    Nops, I am saying you can all doFilter with original request and response.It should be available.

    Or you can check same in single filter by referencing other filters logic in same filter something like below:

    @Override
    public void doFilter(final ServletRequest request, final ServletResponse response, final FilterChain filterChain)
    throws IOException, ServletException {
    doMyJob(request, response, params);
    filterChain.doFilter(request, response);
    }

    I am not sure if is this suitable for your use case.

    Arun Patidar
      joerghoh
      Adobe Employee
      joerghohAdobe EmployeeAccepted solution
      Adobe Employee
      November 15, 2018

      What iterator from the request are you processing?

      (I know that there is an issue when dealing with multi-part POST requiests. If you have functionality which first casts the SlingHttpServletRequest to a HttpServletRequest and reads it using this API, all subsequent calls to read the body will fail, because the input stream has already been consumed. The Sling implementation consumes it already and provides dedicated methods to access it. We came across this a year or two ago, so I don't know the details anymore.)

      S
      swathiv54399501Author
      Level 3
      November 16, 2018

      In filter I am parsing one of the request attribute ('request-parts-iterator') to fetch uploaded file from OOTB DAM upload buttton. I am reading the inputstream stream from it and enabling antivirus scan for the uploaded file. Once scan done, I am doing chain filter(chainfiltter.doFilter(request,response)) but as I already read the Inputstream Once , CreateAssetFilter unable to read the stream again to process upload action.

      I even tried to wrapping of the request. That dint worked too.

      I am totally blocked here.

      Thanks,

      Terms & ConditionsAccessibility statement

      Loading footer...