myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Korherr <jakob.korh...@gmail.com>
Subject Re: Spring FilterSecurityInterceptor not been called for myfaces forwards
Date Wed, 13 Jan 2010 20:01:12 GMT
Can you sort out if the filter itself is not called or if the filter behaves
wrong?


2010/1/13 Madhav Bhargava <Madhav_Bhargava@infosys.com>

> Yeah this is the place.
> Back to the problem. I still cannot come up with a workaround :(
>
> From: sethfromaustria@gmail.com [mailto:sethfromaustria@gmail.com] 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 <Madhav_Bhargava@infosys.com>
> >
> > 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: sethfromaustria@gmail.com [mailto:sethfromaustria@gmail.com] 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 <tompasik@poczta.fm>
> > >
> > > 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
> > >>
> > >>
> > >>
> > >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message