SEC-1614: Status 404 with Apache Tiles #1855

Closed
spring-issuemaster opened this Issue Nov 5, 2010 · 2 comments

1 participant

@spring-issuemaster

Johannes Scharf (Migrated from SEC-1614) said:

We use Apache Tiles 2.1.4 to render our pages. After we've upgraded to Spring Security 3.0.4 we received a "HTTP Status 404" error page from tomcat when accessing some pages.
When we use a custom HttpFirewall and FirewalledRequest, which does nothing, the errors disappear.

As far as I found out all pages are impacted which are "excluded" from Spring Security's FilterChainProxy, as our login and logout pages for example.
I think that issue is related to SEC-1608.

Tiles does various forwards/includes during the rendering phase which (obviously) will change the ServletPath and PathInfo
To track down the error, I've developed a custom "RequestWrapper" which outputs the original and stripped version of the ServletPath and PathInfo:
Constructor - StrippedServletPath: /main - StrippedPathInfo: /login/login.htm
getServletPath() - stripPaths: true - strippedServletPath: /main - servletPath: /main
getPathInfo() - stripPaths: true - strippedPathInfo: /login/login.htm - pathInfo: /login/login.htm
getServletPath() - stripPaths: true - strippedServletPath: /main - servletPath: /main
getServletPath() - stripPaths: true - strippedServletPath: /main - servletPath: /main
getServletPath() - stripPaths: true - strippedServletPath: /main - servletPath: /main
getPathInfo() - stripPaths: true - strippedPathInfo: /login/login.htm - pathInfo: /login/login.htm
getServletPath() - stripPaths: true - strippedServletPath: /main - servletPath: /WEB-INF/layouts/plain.jsp

As you can see at the end of the request the "strippedServletPath" and "servletPath" are different while "stripPaths" is still true. Therefore the "wrong" stripped ServletPath gets returned and Tiles fails to render the response correctly.
getPathInfo() - stripPaths: true - strippedPathInfo: /login/login.htm - pathInfo: null

@spring-issuemaster

Luke Taylor said:

I think this is the same issue. A workaround is to use anonymous authentication attributes instead of excluding the request from the filter chain. Alternatively, you can add an extra filter at the after the security filter chain which calls reset() on the request wrapper.

@spring-issuemaster spring-issuemaster added this to the 3.1.0.M2 milestone Feb 5, 2016
@spring-issuemaster

This issue duplicates #1848

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment