Hi Greg, Colin, Ben
I included the servlet mappings in the web.xml (just the names changed ...
:)
Also my login page that makes the post is like this:
login page:
<form method="POST" action="j_acegi_security_check"> . . .
spring snippet:
. . .
<bean id="authenticationProcessingFilter"
class="net.sf.acegisecurity.ui.webapp.AuthenticationProcessingFilter">
<property name="authenticationManager"><ref
bean="authenticationManager"/></property>
<property
name="authenticationFailureUrl"><value>/login.do</value></property>
<property name="defaultTargetUrl"><value>/</value></property>
<property
name="filterProcessesUrl"><value>/j_acegi_security_check</value></property>
</bean>
<bean id="securityEnforcementFilter"
class="net.sf.acegisecurity.intercept.web.SecurityEnforcementFilter">
<property name="filterSecurityInterceptor"><ref
bean="filterInvocationInterceptor"/></property>
<property name="authenticationEntryPoint"><ref
bean="authenticationProcessingFilterEntryPoint"/></property>
</bean>
<bean id="authenticationProcessingFilterEntryPoint"
class="net.sf.acegisecurity.ui.webapp.AuthenticationProcessingFilterEntryPoint">
<property
name="loginFormUrl"><value>/login.do</value></property>
<property name="forceHttps"><value>false</value></property>
</bean>
. . .
web.xml:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application
2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app id="WebApp">
<display-name>AppName</display-name>
<!--
- Location of the XML file that defines the root application context.
- Applied by ContextLoaderServlet.
-->
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
/WEB-INF/applicationContext.xml
</param-value>
</context-param>
<context-param>
<param-name>log4jConfigLocation</param-name>
<param-value>/WEB-INF/classes/log4j.properties</param-value>
</context-param>
<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>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<servlet>
<servlet-name>action</servlet-name>
<servlet-class>com.app.web.controller.AppActionServlet</servlet-class>
<init-param>
<param-name>config</param-name>
<param-value>WEB-INF/struts-config.xml</param-value>
</init-param>
<init-param>
<param-name>debug</param-name>
<param-value>3</param-value>
</init-param>
<init-param>
<param-name>detail</param-name>
<param-value>2</param-value>
</init-param>
<init-param>
<param-name>validate</param-name>
<param-value>true</param-value>
</init-param>
<load-on-startup>2</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>action</servlet-name>
<url-pattern>*.do</url-pattern>
</servlet-mapping>
<welcome-file-list>
<welcome-file>index.html</welcome-file>
<welcome-file>index.htm</welcome-file>
<welcome-file>index.jsp</welcome-file>
<welcome-file>default.html</welcome-file>
<welcome-file>default.htm</welcome-file>
<welcome-file>default.jsp</welcome-file>
</welcome-file-list>
<taglib>
<taglib-uri>/WEB-INF/struts-bean.tld</taglib-uri>
<taglib-location>/WEB-INF/struts-bean.tld</taglib-location>
</taglib>
. . .
<taglib>
<taglib-uri>/WEB-INF/authz.tld</taglib-uri>
<taglib-location>/WEB-INF/authz.tld</taglib-location>
</taglib>
</web-app>
|---------+--------------------------------------------------->
| | Greg Wilkins <[EMAIL PROTECTED]> |
| | Sent by: |
| | [EMAIL PROTECTED]|
| | ceforge.net |
| | |
| | |
| | 06/15/2004 03:59 PM |
| | Please respond to |
| | acegisecurity-developer |
|---------+--------------------------------------------------->
>----------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED] |
| cc: [EMAIL PROTECTED], |
| [EMAIL PROTECTED], |
| [EMAIL PROTECTED] |
| Subject: Re: [Acegisecurity-developer] Re: HttpServletRequest getters
|
|
|
|
|
>----------------------------------------------------------------------------------------------|
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
-------------------------------------------------------
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