Thanks for this.
But there are no servlet mappings in this fragment. So if there are not servlets, then the default servlet applies and I think the jetty mappings are correct.
cheers
Mark St Godard wrote:
The web.xml (fragment) for the following Websphere 5.1 output (see previous mail) are as follows:
(again pretty standard Acegi config stuff)
.. . . <filter> <filter-name>Acegi Authentication Processing Filter</filter-name>
<filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class> <init-param> <param-name>targetClass</param-name>
<param-value>net.sf.acegisecurity.ui.webapp.AuthenticationProcessingFilter</param-value> </init-param> </filter>
<filter> <filter-name>Acegi Security System for Spring Auto Integration Filter</filter-name>
<filter-class>net.sf.acegisecurity.ui.AutoIntegrationFilter</filter-class> </filter>
<filter> <filter-name>Acegi HTTP Request Security Filter</filter-name>
<filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class> <init-param> <param-name>targetClass</param-name>
<param-value>net.sf.acegisecurity.intercept.web.SecurityEnforcementFilter</param-value> </init-param> </filter>
<filter-mapping> <filter-name>Acegi Authentication Processing Filter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>
<filter-mapping> <filter-name>Acegi Security System for Spring Auto Integration Filter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>
<filter-mapping> <filter-name>Acegi HTTP Request Security Filter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>
. . .
|---------+---------------------------------------------------> | | Greg Wilkins <[EMAIL PROTECTED]> | | | Sent by: | | | [EMAIL PROTECTED]| | | ceforge.net | | | | | | | | | 06/12/2004 02:05 AM | | | Please respond to | | | acegisecurity-developer | |---------+---------------------------------------------------> >----------------------------------------------------------------------------------------------| | | | To: Colin Sampaleanu <[EMAIL PROTECTED]> | | cc: [EMAIL PROTECTED], | | [EMAIL PROTECTED] | | Subject: Re: [Acegisecurity-developer] Re: HttpServletRequest getters | | | | | >----------------------------------------------------------------------------------------------|
Colin,
It is not the filter mappings that controls the servletPath and pathInfo. Rather it is the mapping of the eventual resource that is mapped to.
If there is no resource that the request is targetted to, then the request is mapped to the / default servlet. Then the servletpath should be the request path and the path info null (which is what Jetty has produced).
Any chance you can send the web.xml that generated this, so we can see the exact mapping.
cheers
Colin Sampaleanu wrote:
Greg,
(I'm cc'ing Greg directly also since I am not a jetty mailing list member, and don't know if this will get to Greg otherwise).
It seems to me that this is not actually so clear-cut. The filter in question is not mapped to the request via a <servlet-name>xxxx</servlet-name> in the <filter-mapping> element, but rather a <url-pattern>/*</url-pattern> url mapping. As such, when the filter is executed, as I understand it, it's not even a servlet filter, it's just a general filter on the
request.
As far as I can make it out, both Jetty _and_ WebSphere are wrong. The method definition is:
"Servlet Path: The path section that directly corresponds to the mapping which activated this request. This path starts with a?/? character except in the case where the request is matched with the ?/*? pattern, in which case it is an empty string."
well the mapping that caused the filter to fire in this case is definitely '/*', so I think the method should be returning an empty string. Instead, Jetty (and I think TomCat) return /j_acegi_security_check and WebSphere returns /
How is either of the above correct?
Regards, Colin
Greg Wilkins wrote:
Ben,
The spec says:
"A string containing only the / character indicates the "default"
servlet
of the application. In this case the servlet path is the request URI minus the context path and the path info is null."
"Servlet Path: The path section that directly corresponds to the mapping which activated this request. This path starts with a / character except in the case where the request is matched with the /* pattern, in which case it is an empty string. "
"PathInfo: The part of the request path that is not part of the Context Path or the Servlet Path. It is either null if there is no extra path, or is a string with a leading / .
So looking at your results, Jetty is giving you results as if the mapping was /j_acegi_security_check
I can't think of a legal mapping that would result in the WebSphere result of servlet path=/.
If the mapping was /j_acei_securitycheck, then a sp of / is just wrong.
If the mapping was /* then servletpath must be the empty string and the path info must start with a /
If the mapping was / then the servletpath should be the whole request
URI
and the path info must be null
So websphere is just plain wrong on this one !
cheers
Ben Alex wrote:
Hi everyone
The Acegi Security System for Spring (http://acegisecurity.sourceforge.net) uses HttpServletRequest getters in a filter. I do all the development of the project using Jetty, but we've had a report of problems with WebSphere 5.1.1. I'm writing to the Jetty list in the hope of gaining some clarification as to the correct behaviour of different HttpServletRequest getters.
Here are our filter logging directives:
logger.debug("REQ url: " + httpRequest.getRequestURL()); logger.debug("REQ servlet path: " + httpRequest.getServletPath()); logger.debug("REQ context path: " + httpRequest.getContextPath()); logger.debug("REQ path info: " + httpRequest.getPathInfo()); logger.debug("REQ path translated " + httpRequest.getPathTranslated()); logger.debug("REQ request url: " + httpRequest.getRequestURL());
Using Jetty 4.2.17 it returns:
REQ url: http://localhost:8080/contacts/j_acegi_security_check REQ servlet path: /j_acegi_security_check REQ context path: /contacts REQ path info: null REQ path translated null REQ request url: http://localhost:8080/contacts/j_acegi_security_check
Using WebSphere 5.1.1 (on a different machine) it returns:
REQ url: http://localhost:9080/Permit/j_acegi_security_check REQ servlet path: / REQ context path: /Permit REQ path info: j_acegi_security_check REQ path translated
/home/mark/Repositories/permit/PermitWeb/WebContent/j_acegi_security_check
REQ request url: http://localhost:9080/Permit/j_acegi_security_check
So, is getServletPath() and getPathInfo() correct for Jetty or WebSphere? We're trying to detect the getServletPath() output as per Jetty (ie /j_acegi_security_check) so we know our filter should do something.
Any advice appreciated.
Ben
-- Greg Wilkins<[EMAIL PROTECTED]> Phone/fax: +44 7092063462 Mort Bay Consulting Australia and UK. http://www.mortbay.com
------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND _______________________________________________ Jetty-support mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jetty-support
------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND _______________________________________________ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
