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>
