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
> >>
> >>
> >>
> >
>
>
