Gert, Something to support our discussion: have a look at "(2) invoke filter chain on forwards" on http://www.jroller.com/page/fairTrade. If I use a redirect, the filter gets invoked properly.
Erik -----Oorspronkelijk bericht----- Van: Gert Vanthienen [mailto:[EMAIL PROTECTED] Verzonden: woensdag 20 september 2006 15:25 Aan: MyFaces Discussion Onderwerp: Re: MyFaces, Tomcat and Acegi Integration Problem Erik, The WebXmlParser doesn't recognize the <dispatcher> element, but this is not the component that is responsible for making sure the requests pass the Acegi Security check. The web container (Tomcat) is responsible for performing this task. I don't think the warning message your seeing can cause the filter to be bypassed. That's the reason for my suggestion for trying to get the Acegi filter to work in a simple application and making sure it works there, with only Tomcat to blame if things go wrong. If you want, I can give it a try myself this evening or tomorrow morning. I've been postponing to take a decent look at the Acegi Security filter for too long anyway ;) Regards, Gert Vanthienen [EMAIL PROTECTED] GOVAERS Erik wrote: > Gert, > > Thanks for your reply. I added the <dispatcher> elements as described in > http://wiki.apache.org/myfaces/JSF_and_Acegi to make sure that <jsp:forward> > requests are captured by the Acegi Filter. Because they are not recognized by > the WebXmlParser, forward requests can bypass the Acegi Security check. > No, I haven't tried it in a simple sample application. > > Erik > > -----Oorspronkelijk bericht----- > Van: Gert Vanthienen [mailto:[EMAIL PROTECTED] > Verzonden: woensdag 20 september 2006 14:39 > Aan: MyFaces Discussion > Onderwerp: Re: MyFaces, Tomcat and Acegi Integration Problem > > > Erik, > > > I have taken a quick look at the source code of WebXmlParser. It > currently doesn't have any awareness of the <web-app > version="2.4".../>-style web.xml, causing it to ignore the 'dispatcher' > element (which did not exist prior to version 2.4 of the servlet spec), > hence the warning. However, this is a merely a warning and it doesn't > change the behavior of MyFaces, as far as I can see. I'm almost certain > it doesn't modify the way Tomcat handles this filter-mapping. > > Have you tried using this filter configuration in a simple (only for > testing purposes) web application with no JSF, only plain JSPs and > Servlets? Does it work correctly in these simplified circumstances? > > > Regards, > > Gert Vanthienen > [EMAIL PROTECTED] > > GOVAERS Erik wrote: > >> Hello, >> >> I'm using MyFaces with the Spring Framework and Acegi for building a secured >> web application. Here's my configuration: >> Tomcat 5.0.28 >> MyFaces 1.1.3 >> >> Tomahawk 1.1.3 >> Servlets 2.4 (correct header in web.xml, see attachment) >> To make sure that a jsp forward request is intercepted by Acegi, I added the >> <dispatcher> elements to the Acegi filter mapping entry in my web.xml as >> described in <http://wiki.apache.org/myfaces/JSF_and_Acegi>. >> When I start Tomcat, I get the following warning: "Ignored element >> 'dispatcher' as child of 'filter-mapping'.", generated by the FilterMapping >> method in org.apache.myfaces.shared_impl.webapp.webxml.WebXmlParser. I also >> noticed that jsp forward actions aren't caught by Acegi. Has anybody any >> idea what I am doing wrong here? The WebXmlParser is part of the >> tomahawk-1.1.3.jar. >> >> Kind regards, >> Erik Govaers >> >> >> >> >> >> Erik Govaers >> Medewerker Gehandicaptenzorg >> Dienst Welzijn Provincie Antwerpen >> Boomgaardstraat 22 >> 2600 Berchem >> Tel.: 03/240 56 72 >> Fax: 03/240 61 62 >> >> >> ------------------------------------------------------------------------ >> >> <?xml version="1.0" encoding="UTF-8"?> >> >> <web-app >> id="WebApp_ID" >> version="2.4" >> xmlns="http://java.sun.com/xml/ns/j2ee"; >> xmlns:xsi="http://java.sun.com/xml/ns/j2ee >> http://www.w3.org/2001/XMLSchema-instance"; >> xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee >> http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd";> >> >> <!-- This web.xml can be used during debugging, when there is no >> myfaces.jar >> library available. >> >> The faces-config.xml file (that is normally in the myfaces.jar) >> must be >> copied to the /WEB-INF directory of the web context. >> >> The TLDs (that are normally in the myfaces.jar) must be >> copied to the /WEB-INF/lib directory of the web context.--> >> <description>debug web.xml</description> >> >> <context-param> >> <param-name>javax.faces.CONFIG_FILES</param-name> >> <param-value>/WEB-INF/faces-navigation.xml</param-value> >> </context-param> >> >> <context-param> >> <param-name>javax.faces.STATE_SAVING_METHOD</param-name> >> <param-value>server</param-value> >> <description> >> State saving method: "client" or "server" (= default) >> See >> JSF Specification 2.5.2 >> </description> >> </context-param> >> >> <context-param> >> <param-name>org.apache.myfaces.ALLOW_JAVASCRIPT</param-name> >> <param-value>true</param-value> >> <description> >> This parameter tells MyFaces if javascript code should >> be >> allowed in the rendered HTML output. If javascript is >> allowed, command_link anchors will have javascript code >> that >> submits the corresponding form. If javascript is not >> allowed, the state saving info and nested parameters >> will be >> added as url parameters. Default: "true" >> </description> >> </context-param> >> >> <context-param> >> <param-name>org.apache.myfaces.DETECT_JAVASCRIPT</param-name> >> <param-value>false</param-value> >> </context-param> >> >> <context-param> >> <param-name>org.apache.myfaces.PRETTY_HTML</param-name> >> <param-value>true</param-value> >> <description> >> If true, rendered HTML code will be formatted, so that >> it is >> "human readable". i.e. additional line separators and >> whitespace will be written, that do not influence the >> HTML >> code. Default: "true" >> </description> >> </context-param> >> >> <context-param> >> <param-name>org.apache.myfaces.AUTO_SCROLL</param-name> >> <param-value>true</param-value> >> <description> >> If true, a javascript function will be rendered that is >> able >> to restore the former vertical scroll on every request. >> Convenient feature if you have pages with long lists >> and you >> do not want the browser page to always jump to the top >> if >> you trigger a link or button action that stays on the >> same >> page. Default: "false" >> </description> >> </context-param> >> >> <context-param> >> >> <param-name>org.apache.myfaces.CHECK_EXTENSIONS_FILTER</param-name> >> <param-value>false</param-value> >> </context-param> >> >> <context-param> >> <param-name>org.apache.myfaces.ADD_RESOURCE_CLASS</param-name> >> >> <param-value>org.apache.myfaces.component.html.util.StreamingAddResource</param-value> >> </context-param> >> >> <context-param> >> >> <param-name>org.apache.myfaces.COMPRESS_STATE_IN_SESSION</param-name> >> <param-value>false</param-value> >> </context-param> >> >> <context-param> >> >> <param-name>org.apache.myfaces.SERIALIZE_STATE_IN_SESSION</param-name> >> <param-value>false</param-value> >> </context-param> >> >> <!-- Tiles ViewHandler config file --> >> >> <context-param> >> <param-name>tiles-definitions</param-name> >> <param-value>/WEB-INF/tiles.xml</param-value> >> <description> >> Tiles configuration definition files and a listener >> need to >> be defined. the listener will initialize >> JspTilesViewHandlerImpl with tiles definitions. >> </description> >> </context-param> >> >> <!-- >> - Location of the XML file that defines the root application >> context. >> - Applied by ContextLoaderServlet. >> - >> - Can include "/WEB-INF/dataAccessContext-local.xml" for a >> single-database >> - context >> --> >> <context-param> >> <param-name>contextConfigLocation</param-name> >> <param-value> >> >> /WEB-INF/dataAccessContext-local.xml,/WEB-INF/applicationContext.xml,/WEB-INF/securityContext.xml >> </param-value> >> </context-param> >> >> <!-- - - - - - - - ACEGI FILTERS - - - - - - - - --> >> >> <filter> >> <filter-name>Acegi Filter Chain Proxy</filter-name> >> <filter-class> >> org.acegisecurity.util.FilterToBeanProxy >> </filter-class> >> <init-param> >> <param-name>targetClass</param-name> >> <param-value> >> org.acegisecurity.util.FilterChainProxy >> </param-value> >> </init-param> >> </filter> >> >> <!-- - - - - - - - END ACEGI FILTERS - - - - - - - - --> >> >> <!-- EXTENSIONS FILTER --> >> >> <filter> >> <filter-name>extensionsFilter</filter-name> >> <filter-class> >> org.apache.myfaces.webapp.filter.ExtensionsFilter >> </filter-class> >> <init-param> >> <param-name>uploadMaxFileSize</param-name> >> <param-value>100m</param-value> >> <description> >> Set the size limit for uploaded files. Format: >> 10 - 10 >> bytes 10k - 10 KB 10m - 10 MB 1g - 1 GB >> </description> >> </init-param> >> <init-param> >> <param-name>uploadThresholdSize</param-name> >> <param-value>100k</param-value> >> <description> >> Set the threshold size - files below this limit >> are >> stored in memory, files above this limit are >> stored on >> disk. >> >> Format: 10 - 10 bytes 10k - 10 KB 10m - 10 MB >> 1g - 1 GB >> </description> >> </init-param> >> <!-- <init-param> >> <param-name>uploadRepositoryPath</param-name> >> <param-value>/temp</param-value> >> <description>Set the path where the intermediary files >> will be stored. >> </description> >> </init-param>--> >> </filter> >> >> <filter-mapping> >> <filter-name>Acegi Filter Chain Proxy</filter-name> >> <url-pattern>/*</url-pattern> >> <dispatcher>FORWARD</dispatcher> >> <dispatcher>REQUEST</dispatcher> >> </filter-mapping> >> >> <filter-mapping> >> <filter-name>extensionsFilter</filter-name> >> <url-pattern>*.jsf</url-pattern> >> </filter-mapping> >> >> <filter-mapping> >> <filter-name>extensionsFilter</filter-name> >> <url-pattern>/faces/*</url-pattern> >> </filter-mapping> >> >> <!-- extension mapping for adding <script/>, <link/>, and other >> resource tags to JSF-pages --> >> <filter-mapping> >> <filter-name>extensionsFilter</filter-name> >> <!-- servlet-name must match the name of your >> javax.faces.webapp.FacesServlet entry --> >> <servlet-name>Faces Servlet</servlet-name> >> </filter-mapping> >> >> <!-- >> - Loads the root application context of this web app at startup, >> - by default from "/WEB-INF/applicationContext.xml". >> - Note that you need to fall back to Spring's >> ContextLoaderServlet for >> - J2EE servers that do not follow the Servlet 2.4 >> initialization order. >> - >> - Use >> WebApplicationContextUtils.getWebApplicationContext(servletContext) >> - to access it anywhere in the web application, outside of the >> framework. >> - >> - The root context is the parent of all servlet-specific >> contexts. >> - This means that its beans are automatically available in >> these child contexts, >> - both for getBean(name) calls and (external) bean references. >> --> >> <listener> >> <listener-class> >> org.springframework.web.context.ContextLoaderListener >> </listener-class> >> </listener> >> >> <!-- FACES SERVLET --> >> >> <servlet> >> <servlet-name>SourceCodeServlet</servlet-name> >> >> <servlet-class>org.apache.myfaces.shared_tomahawk.util.servlet.SourceCodeServlet</servlet-class> >> </servlet> >> >> <servlet> >> <servlet-name>Faces Servlet</servlet-name> >> <servlet-class>javax.faces.webapp.FacesServlet</servlet-class> >> <load-on-startup>1</load-on-startup> >> </servlet> >> >> <!-- Faces Servlet Mapping --> >> >> <!-- extension mapping --> >> <servlet-mapping> >> <servlet-name>Faces Servlet</servlet-name> >> <url-pattern>*.jsf</url-pattern> >> </servlet-mapping> >> >> <!-- WELCOME FILES --> >> >> <welcome-file-list> >> <!-- <welcome-file>index.jsp</welcome-file> --> >> <welcome-file>index.html</welcome-file> >> <!-- <welcome-file>./pages/web/homePage.jsp</welcome-file> --> >> </welcome-file-list> >> >> </web-app> >> >> > > >
