Gert, Thanks a million, it works! I can now use <jsp:forward> with a significant performance gain whenever I don't need to redirect. It's a good thing you added this information to the Wiki, because in all my searches for a solution, I never came accross it.
Thanks again, Erik -----Oorspronkelijk bericht----- Van: Gert Vanthienen [mailto:[EMAIL PROTECTED] Verzonden: woensdag 20 september 2006 22:38 Aan: MyFaces Discussion Onderwerp: Re: MyFaces, Tomcat and Acegi Integration Problem Erik, After some investigation, I found out that the problem was unrelated to MyFaces (the problem also occurs when using <jsp:forward/> in plain JSPs) and to Tomcat (it also appears when using Geronimo with Jetty as the web container). Some further research in the Spring mailing lists and JIRA [1, 2, 3] has provided me with a solution. It appears the problem has been solved since Acegi Security 0.9.0 with an additional property being added to org.acegisecurity.intercept.web.FilterSecurityInterceptor named observeOncePerRequest. When setting this boolean property to false, the Acegi Security filter chain is triggered more than once per request, resulting in the correct behavior when using <jsp:forward />. To solve your problem, it is probably sufficient to add a <property /> element to your Acegi configuration file: <bean id="filterInvocationInterceptor" class="org.acegisecurity.intercept.web.FilterSecurityInterceptor"> ... <property name="observeOncePerRequest" value="false"/> </bean> I have also added this information to the wiki page on JSF and Acegi [4] and I have opened a JIRA issue [5] for the unnecessary warning messages being shown for the <dispatcher/> elements in web.xml. Hope this helps, Gert Vanthienen [EMAIL PROTECTED] [1] http://forum.springframework.org/archive/index.php/t-11025.html [2] http://opensource.atlassian.com/projects/spring/browse/SEC-14 [3] http://forum.springframework.org/showthread.php?t=15291 [4] http://wiki.apache.org/myfaces/JSF_and_Acegi [5] https://issues.apache.org/jira/browse/MYFACES-1415 GOVAERS Erik wrote: > Gert, > > If you can find the time to try it out, please do. The one thing I noticed is > that when I use a <jsp:forward> to send the user to a page which he/she is > not authorised to see, he/she can access it nonetheless. > > Regards, > > 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> >>> >>> >>> >> >> > > > >
