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

Reply via email to