Yeah this is the place. Back to the problem. I still cannot come up with a workaround :(
From: [email protected] [mailto:[email protected]] On Behalf Of Jakob Korherr >The "magic" happens in JspViewHandlerImpl's renderView() method: > >public void renderView(FacesContext facesContext, UIViewRoot viewToRender) > throws IOException, FacesException { > externalContext.dispatch(viewId); > .... > > } > >Regards, >Jakob > >2010/1/13 Madhav Bhargava <[email protected]> > > Yes, I am not using facelets. > I had a look at the NavigationHandlerImpl and here is the excerpt from it: > > Method: handleNavigation > > if (navigationCase != null) > { > if (log.isTraceEnabled()) > { > log.trace("handleNavigation fromAction=" + fromAction + " > outcome=" + outcome + > " toViewId =" + navigationCase.getToViewId() + > " redirect=" + navigationCase.isRedirect()); > } > if (navigationCase.isRedirect() && > (!PortletUtil.isPortletRequest(facesContext))) > { // Spec section 7.4.2 says "redirects not possible" in this > case for portlets > ExternalContext externalContext = > facesContext.getExternalContext(); > ViewHandler viewHandler = > facesContext.getApplication().getViewHandler(); > String redirectPath = viewHandler.getActionURL(facesContext, > navigationCase.getToViewId()); > > try > { > > externalContext.redirect(externalContext.encodeActionURL(redirectPath)); > } > catch (IOException e) > { > throw new FacesException(e.getMessage(), e); > } > } > else > { > ViewHandler viewHandler = > facesContext.getApplication().getViewHandler(); > //create new view > String newViewId = navigationCase.getToViewId(); > UIViewRoot viewRoot = null; > if (isPartialStateSavingOn(facesContext)) { > viewRoot = > viewHandler.restoreView(facesContext,newViewId); > } else { > viewRoot = viewHandler.createView(facesContext, > newViewId); > } > facesContext.setViewRoot(viewRoot); > facesContext.renderResponse(); > } > > In the above code, redirect happens properly however for a forward there is > no RequestDispatcher.forward or ExternalContext.dispatch called. So I do not > know where a forward happens. > > Regards, > Madhav > > From: [email protected] [mailto:[email protected]] On > Behalf Of Jakob Korherr > >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 > >> > >> > >> > > > >
