You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by dusty <du...@yahoo.com> on 2008/12/29 19:19:56 UTC
Warning: Spring Security and FileUploadInterceptor filter order
Hello,
This vexed me, so I thought I would share to help anyone stuck with
something similar....
I have Spring Security protecting my Struts2 app. Originally I had my
filters setup like this:
<filter-mapping>
<filter-name>struts-prepare</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>securityFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>sitemesh</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>lazyLoadingFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>struts-execute</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
The problem is that the FileUploadInterceptor looks at the request and tries
to cast it to the Struts2 wrapper MultiPartRequestWrapper. With the Spring
Security filter where it is above, the Struts2 dispatcher wraps the request
(when it detects multipart/form-data) but then Spring Security builds its
own request wrapper class for the request. The FileUploadInterceptor
doesn't think its a MultiPartRequest and doesn't populate the setters on
your action.
The answer is to put Spring Security first:
<filter-mapping>
<filter-name>securityFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>struts-prepare</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>sitemesh</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>lazyLoadingFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>struts-execute</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
This way Spring Security does its thing and then Struts builds its wrapper
after the user is authenticated. Knowing what I know now it seems obvious
to put the Spring Security filter first, but I guess it wasn't that obvious
to me originally. So maybe someone else will miss that as well and somehow
google this post....
--
View this message in context: http://www.nabble.com/Warning%3A--Spring-Security-and-FileUploadInterceptor-filter-order-tp21207025p21207025.html
Sent from the Struts - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Warning: Spring Security and FileUploadInterceptor filter order
Posted by Nils-Helge Garli Hegvik <ni...@gmail.com>.
Hi!
If you think you have found a bug in Struts 2, please register an
issue in the issue tracker at
https://issues.apache.org/struts/secure/Dashboard.jspa
Thanks.
Nils-H
On Mon, Dec 29, 2008 at 7:19 PM, dusty <du...@yahoo.com> wrote:
>
> Hello,
>
> This vexed me, so I thought I would share to help anyone stuck with
> something similar....
>
> I have Spring Security protecting my Struts2 app. Originally I had my
> filters setup like this:
> <filter-mapping>
> <filter-name>struts-prepare</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
> <filter-mapping>
> <filter-name>securityFilter</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
> <filter-mapping>
> <filter-name>sitemesh</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
> <filter-mapping>
> <filter-name>lazyLoadingFilter</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
> <filter-mapping>
> <filter-name>struts-execute</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
>
> The problem is that the FileUploadInterceptor looks at the request and tries
> to cast it to the Struts2 wrapper MultiPartRequestWrapper. With the Spring
> Security filter where it is above, the Struts2 dispatcher wraps the request
> (when it detects multipart/form-data) but then Spring Security builds its
> own request wrapper class for the request. The FileUploadInterceptor
> doesn't think its a MultiPartRequest and doesn't populate the setters on
> your action.
>
> The answer is to put Spring Security first:
> <filter-mapping>
> <filter-name>securityFilter</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
> <filter-mapping>
> <filter-name>struts-prepare</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
> <filter-mapping>
> <filter-name>sitemesh</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
> <filter-mapping>
> <filter-name>lazyLoadingFilter</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
> <filter-mapping>
> <filter-name>struts-execute</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
>
> This way Spring Security does its thing and then Struts builds its wrapper
> after the user is authenticated. Knowing what I know now it seems obvious
> to put the Spring Security filter first, but I guess it wasn't that obvious
> to me originally. So maybe someone else will miss that as well and somehow
> google this post....
> --
> View this message in context: http://www.nabble.com/Warning%3A--Spring-Security-and-FileUploadInterceptor-filter-order-tp21207025p21207025.html
> Sent from the Struts - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Warning: Spring Security and FileUploadInterceptor filter order
Posted by Musachy Barroso <mu...@gmail.com>.
could you add this to the wiki? thanks for letting us know.
musachy
On Mon, Dec 29, 2008 at 1:19 PM, dusty <du...@yahoo.com> wrote:
>
> Hello,
>
> This vexed me, so I thought I would share to help anyone stuck with
> something similar....
>
> I have Spring Security protecting my Struts2 app. Originally I had my
> filters setup like this:
> <filter-mapping>
> <filter-name>struts-prepare</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
> <filter-mapping>
> <filter-name>securityFilter</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
> <filter-mapping>
> <filter-name>sitemesh</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
> <filter-mapping>
> <filter-name>lazyLoadingFilter</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
> <filter-mapping>
> <filter-name>struts-execute</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
>
> The problem is that the FileUploadInterceptor looks at the request and tries
> to cast it to the Struts2 wrapper MultiPartRequestWrapper. With the Spring
> Security filter where it is above, the Struts2 dispatcher wraps the request
> (when it detects multipart/form-data) but then Spring Security builds its
> own request wrapper class for the request. The FileUploadInterceptor
> doesn't think its a MultiPartRequest and doesn't populate the setters on
> your action.
>
> The answer is to put Spring Security first:
> <filter-mapping>
> <filter-name>securityFilter</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
> <filter-mapping>
> <filter-name>struts-prepare</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
> <filter-mapping>
> <filter-name>sitemesh</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
> <filter-mapping>
> <filter-name>lazyLoadingFilter</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
> <filter-mapping>
> <filter-name>struts-execute</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
>
> This way Spring Security does its thing and then Struts builds its wrapper
> after the user is authenticated. Knowing what I know now it seems obvious
> to put the Spring Security filter first, but I guess it wasn't that obvious
> to me originally. So maybe someone else will miss that as well and somehow
> google this post....
> --
> View this message in context: http://www.nabble.com/Warning%3A--Spring-Security-and-FileUploadInterceptor-filter-order-tp21207025p21207025.html
> Sent from the Struts - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org