myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gert Vanthienen <gert.vanthie...@skynet.be>
Subject Re: MyFaces, Tomcat and Acegi Integration Problem
Date Wed, 20 Sep 2006 20:38:19 GMT
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
gert@anova.be


[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:gert.vanthienen@skynet.be]
> 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
> gert@anova.be
>
> 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:gert.vanthienen@skynet.be]
>> 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
>> gert@anova.be
>>
>> 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>
>>>   
>>>     
>>>       
>>   
>>     
>
>
>
>   


Mime
View raw message