Hi Tomasz, That's all correct! However, I don't think he is using Facelets, because he mentioned JSP-pages...
Regards, Jakob 2010/1/12 Tomasz Pasierb <[email protected]> > Hi, > > as I understand you use a commandButton and as a result a different page (a > secured one) is rendered but spring security does not seem to intercept the > url, is that right? > > If so and if the solution used by you uses Facelets then this may be the > problem. > When using Facelets as opposed to "pure" (older) jsf+jsp approach there is > no forward when a new view is rendered that is a result of a navigation case > forward. I've been investigating this recently. When JSP view handler is > used it checks which view should be rendered next and does a forward to this > new view which spring security can intercept. The Facelet view handler > however seems to load the view (xhtml) and render it without making the > actual forward. As a result no interception can happen and usually it is > triggered with the next request. > You need to either use redirects or make GET requests to logically separate > views - I know this is not natural with jsf versions prior to 2.0, but this > new spec seems to change everything :-) - use can easily generate GET > requests with the new version. > > Hope this helps ;) > > Regards, > Tom Pasierb > > Madhav Bhargava pisze: > > Hi All, >> >> I am using myfaces 1.1, icefaces 1.8.1, spring 2.5.6, spring security >> -2.0.5, WAS 6.0 (app server) >> >> I have configured spring security for my JSF application along with >> SiteMinder as an external authentication mechanism. It works fine till a >> forward happens from within myfaces. >> >> Here is my spring servlet filter chain declaration: >> <filter> >> <description> >> Spring delegating filter which will >> initiate the spring >> security filter chain >> </description> >> <display-name>springSecurityFilterChain</display-name> >> <filter-name>springSecurityFilterChain</filter-name> >> <filter-class> >> >> org.springframework.web.filter.DelegatingFilterProxy >> </filter-class> >> </filter> >> >> <filter-mapping> >> <filter-name>springSecurityFilterChain</filter-name> >> <url-pattern>/*</url-pattern> >> <dispatcher>FORWARD</dispatcher> >> <dispatcher>REQUEST</dispatcher> >> </filter-mapping> >> >> And in my spring application context I have followed the advice from >> spring forums and done necessary settings: >> Excerpt is: >> >> <security:http >> >> entry-point-ref="preAuthenticatedProcessingFilterEntryPoint" >> once-per-request="false"> >> <security:intercept-url pattern="/index.jsp" filters="none" >> /> >> <security:intercept-url pattern="/login.jsp" filters="none" >> /> >> <security:intercept-url pattern="/authenticationservlet" >> filters="none"/> >> <security:intercept-url pattern="**/jsp/common/**" >> filters="none"/> >> <security:intercept-url pattern="/**/css/**" >> filters="none"/> >> <security:intercept-url pattern="/**/*.js" filters="none"/> >> <security:intercept-url pattern="/images/**" >> filters="none"/> >> <security:intercept-url pattern="/**/secure/**" >> access="ROLE_USER" /> >> <security:intercept-url pattern="/**/operations/**" >> access="ROLE_OPERATIONS"/> >> <security:intercept-url pattern="/**" >> access="IS_AUTHENTICATED_ANONYMOUSLY" /> >> </security:http> >> >> Now when I forward a request from index.jsp to login.jsp then the spring >> filters are called with the login.jsp URL even though the browser shows the >> old URL. >> >> However when from within an action method a navigation case is handled >> then it is not intercepted by the spring filters at all. However if I give a >> <redirect/> then it is properly intercepted with the correct URL as >> expected. >> >> What can be the reason? >> >> Regards, >> Madhav >> >> >> >
