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
_______________________________________________
Acegisecurity-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
