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-namestruts-prepare/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namesecurityFilter/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namesitemesh/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namelazyLoadingFilter/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namestruts-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-namesecurityFilter/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namestruts-prepare/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namesitemesh/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namelazyLoadingFilter/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namestruts-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-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Warning: Spring Security and FileUploadInterceptor filter order
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 dustin_pea...@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-namestruts-prepare/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namesecurityFilter/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namesitemesh/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namelazyLoadingFilter/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namestruts-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-namesecurityFilter/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namestruts-prepare/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namesitemesh/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namelazyLoadingFilter/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namestruts-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-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Warning: Spring Security and FileUploadInterceptor filter order
could you add this to the wiki? thanks for letting us know. musachy On Mon, Dec 29, 2008 at 1:19 PM, dusty dustin_pea...@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-namestruts-prepare/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namesecurityFilter/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namesitemesh/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namelazyLoadingFilter/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namestruts-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-namesecurityFilter/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namestruts-prepare/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namesitemesh/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namelazyLoadingFilter/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namestruts-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-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org -- Hey you! Would you help me to carry the stone? Pink Floyd - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
