Thanks for your response Jakob. What you have mentioned is already known to me. That is the reason I have put a <dispatcher>FORWARD</dispatcher> For Spring security filter.
I should have made it a little more clear. Apologies for that. The forward from index.jsp to login.jsp is via <jsp:forward>. These are not JSF pages. This forward is captured by Spring security filter. However when a forward happens from within JSF via NavigationHandler then this forward is not caught by spring security filter. I am not sure why a jsp:forward forward will be caught every time and not when done via myfaces. So essentially I not worried about browser showing me the previous URL because that is an expected behavior but the new URL is always caught by the filter which in my case is the exact problem. Regards, Madhav >-----Original Message----- >From: [email protected] [mailto:[email protected]] On Behalf >Of Jakob Korherr >Sent: Tuesday, January 12, 2010 4:21 AM >To: MyFaces Discussion >Subject: Re: Spring FilterSecurityInterceptor not been called for myfaces >forwards > >Hi Madhav, > >JSF always submits back to the original view, if you hit a h:commandButton >or h:commandLink. So if you are on index.jsp and hit for example a >h:commandLink, you will get a request for index.jsp. However, after the >action method on the server is finished, the server renders the new view, >depending on the outcome of the action method, in your case login.jsp. But >your browser still displays index.jsp in the address bar, because that was >the page you requested. > >When you add <redirect /> in the faces-config, JSF will instead of just >rendering the new view, redirect to it. Thus you have a second http round >trip and your browser's address bar will display the new view. > >I hope this explains things. > >Regards, >Jakob Korherr 2010/1/11 Madhav Bhargava <[email protected]> > 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 >
