The method
org.geoserver.test.GeoServerSystemTestSupport.createRequest(String)
creates an MockHttpServletRequest object for testing. If you call with “/foo/bar”, the servlet path is “/foo” and the pathinfo is “/bar”. All our elements in web.xml map all filters to “/*”.
IMHO, in this case, the servlet path has to be “” (empty String) and the path info has to be “/foo/bar”. I detected this issue during working on the security filter tests and I found this
http://bluxte.net/musings/2006/03/29/servletpath-and-pathinfo-servlet-api-weirdness
I want to ask here because I am not 100% sure, but I believe we should fix this.
I think this will have unintended side affects if we do that. With the “advanced dispatch” that was added for GeoServer 2.1 we hack the servlet path and path info in order to make servlet paths pluggable. See the AdavncedDispatchFilter for details. You will also notice that that filter actually ignores MockHttpServletRequest requests… although i can’t remember why.
On Sat, Nov 3, 2012 at 9:29 AM, Christian Mueller <mcrmcr21@anonymised.com> wrote:
The method
org.geoserver.test.GeoServerSystemTestSupport.createRequest(String)
creates an MockHttpServletRequest object for testing. If you call with “/foo/bar”, the servlet path is “/foo” and the pathinfo is “/bar”. All our elements in web.xml map all filters to “/*”.
IMHO, in this case, the servlet path has to be “” (empty String) and the path info has to be “/foo/bar”. I detected this issue during working on the security filter tests and I found this
http://bluxte.net/musings/2006/03/29/servletpath-and-pathinfo-servlet-api-weirdness
I want to ask here because I am not 100% sure, but I believe we should fix this.
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Got it. A look into web.xml shows me that the security filter is applied before the advanced dispatch filter. ServletPath and pathinfo used by the security filters are not preprocessed by the advanced dispatch filter.
The security tests override the createRequest method, anything works fine.
As a consequence for web.xml, the filter mapping for the filterchainproxy MUST always be before the mapping for the advanced dispatch filter, otherwise the security system will not work.
Good to know 
2012/11/5 Justin Deoliveira <jdeolive@anonymised.com>
I think this will have unintended side affects if we do that. With the “advanced dispatch” that was added for GeoServer 2.1 we hack the servlet path and path info in order to make servlet paths pluggable. See the AdavncedDispatchFilter for details. You will also notice that that filter actually ignores MockHttpServletRequest requests… although i can’t remember why.
On Sat, Nov 3, 2012 at 9:29 AM, Christian Mueller <mcrmcr21@anonymised.com> wrote:
The method
org.geoserver.test.GeoServerSystemTestSupport.createRequest(String)
creates an MockHttpServletRequest object for testing. If you call with “/foo/bar”, the servlet path is “/foo” and the pathinfo is “/bar”. All our elements in web.xml map all filters to “/*”.
IMHO, in this case, the servlet path has to be “” (empty String) and the path info has to be “/foo/bar”. I detected this issue during working on the security filter tests and I found this
http://bluxte.net/musings/2006/03/29/servletpath-and-pathinfo-servlet-api-weirdness
I want to ask here because I am not 100% sure, but I believe we should fix this.
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Justin, after you reviewed my patch, I will do some minor changes to the authentication filters making them work independent of the order of the filter-mappings in web.xml.
2012/11/5 Christian Mueller <mcrmcr21@anonymised.com>
Got it. A look into web.xml shows me that the security filter is applied before the advanced dispatch filter. ServletPath and pathinfo used by the security filters are not preprocessed by the advanced dispatch filter.
The security tests override the createRequest method, anything works fine.
As a consequence for web.xml, the filter mapping for the filterchainproxy MUST always be before the mapping for the advanced dispatch filter, otherwise the security system will not work.
Good to know
2012/11/5 Justin Deoliveira <jdeolive@anonymised.com>
I think this will have unintended side affects if we do that. With the “advanced dispatch” that was added for GeoServer 2.1 we hack the servlet path and path info in order to make servlet paths pluggable. See the AdavncedDispatchFilter for details. You will also notice that that filter actually ignores MockHttpServletRequest requests… although i can’t remember why.
On Sat, Nov 3, 2012 at 9:29 AM, Christian Mueller <mcrmcr21@anonymised.com> wrote:
The method
org.geoserver.test.GeoServerSystemTestSupport.createRequest(String)
creates an MockHttpServletRequest object for testing. If you call with “/foo/bar”, the servlet path is “/foo” and the pathinfo is “/bar”. All our elements in web.xml map all filters to “/*”.
IMHO, in this case, the servlet path has to be “” (empty String) and the path info has to be “/foo/bar”. I detected this issue during working on the security filter tests and I found this
http://bluxte.net/musings/2006/03/29/servletpath-and-pathinfo-servlet-api-weirdness
I want to ask here because I am not 100% sure, but I believe we should fix this.
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.