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 Mon, 18 Jan 2010 11:11:41 GMT
I'm really sorry, but I can't figure out the problem. Maybe anyone else
could take a look at this log...


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

>  Attached is the log file. Look for lined which have (URLInterceptor.java)
> This will give you the URL that has been intercepted by the custom filter
> which sits before any spring filter. Right now all it does is print out the
> URL that it intercepted.
>
> To refresh your memory here is the flow again in brief:
>
> 1. *http://localhost:9080/contextRoot/*<http://localhost:9080/contextRoot/>is invoked
and it internally it redirects it to the welcome page
> (/index.jsp)
> 2. index.jsp does a <jsp:forward> to /login.jsp
> 3. User enters the credentials and as of now since we do not have
> Siteminder for authentication the action attribute points to
> /jsp/secure/hprelanding.jspx (first JSF page) so a redirect is send.
> 4. On hprelanding page an automatic click happens on a hidden command
> button which calls a backing bean action method. Since I am using icefaces
> the click of a button request is sent using the URL: *
> http://localhost:9080/HPRE/block/**send-receive-updates*<http://localhost:9080/HPRE/block/send-receive-updates>
> 5. You will find many other URL's in between which is all caused by
> icefaces.
> 6. The action method will do nothing but forward the request to
> operationlanding.jspx page which should only be visible to users who have
> ROLE_OPERATIONS however that URL never comes up. Instead the next URL of
> importance is again hprelanding.jspx one.
>
> Regards,
> Madhav
>
> >From: sethfromaustria@gmail.com [mailto:sethfromaustria@gmail.com<sethfromaustria@gmail.com>]
> On Behalf Of Jakob Korherr
> >Sent: Monday, January 18, 2010 3:45 PM
> >
> >It would be great to see some logs!
> >
> >2010/1/18 Madhav Bhargava <Madhav_Bhargava@infosys.com>
> >
> > Sorry for the confusion. There was some problem with log4j configuration
> on
> > WAS 6 and therefore I was not able to generate DEBUG logs out of spring
> > security. The issue turned out to be a ws-commons-logging.jar. Anyways
> back
> > to the issue:
> >
> > In the log it shows that the filter is actually getting called but with
> an
> > older URL. So the spring security filter configuration is fine but now
> it’s
> > the problem only with JSF. The <jsp:forward> thing works fine as I am
> doing
> > a forward from index.jsp to login.jsp
> >
> > If you want the DEBUG logs then I can provide them.
> >
> > Regards,
> > Madhav
> >
> > >From: sethfromaustria@gmail.com [mailto:sethfromaustria@gmail.com<sethfromaustria@gmail.com>]
> On
> > Behalf Of Jakob Korherr
> > >
> > >»The spring security filters are not invoked at all when a JSF forward
> > >happens.«
> > >
> > >Then the issue has to be a misconfiguration problem, because a normal
> > filter
> > >is called for the JSF forward (I tested that). However, I don't know
> > spring
> > >security filters well enough to point out what the real problem is.
> sorry!
> > >
> > >
> > >2010/1/18 Madhav Bhargava <Madhav_Bhargava@infosys.com>
> > >
> > > Sorry for the delay in response. The spring security filters are not
> > > invoked at all when a JSF forward happens.
> > > What we have done as a workaround is that login page has now been made
> a
> > > simple non JSF JSP. We redirect from login page to another page which
> is
> > > just a dummy page. This redirect causes spring security to set up
> > > SecurityContext properly. So we are able to use spring security
> component
> > > level authorizations properly. However the URL level authorization is
> > still
> > > an issue.
> > >
> > > Regards,
> > > Madhav
> > >
> > > >From: sethfromaustria@gmail.com [mailto:sethfromaustria@gmail.com<sethfromaustria@gmail.com>]
> On
> > > Behalf Of Jakob Korherr
> > > >
> > > 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<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<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
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> > **************** CAUTION - Disclaimer *****************
> > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended
> > solely
> > for the use of the addressee(s). If you are not the intended recipient,
> > please
> > notify the sender by e-mail and delete the original message. Further, you
> > are not
> > to copy, disclose, or distribute this e-mail or its contents to any other
> > person and
> > any such actions are unlawful. This e-mail may contain viruses. Infosys
> has
> > taken
> > every reasonable precaution to minimize this risk, but is not liable for
> > any damage
> > you may sustain as a result of any virus in this e-mail. You should carry
> > out your
> > own virus checks before opening the e-mail or attachment. Infosys
> reserves
> > the
> > right to monitor and review the content of all messages sent to or from
> > this e-mail
> > address. Messages sent to or from this e-mail address may be stored on
> the
> > Infosys e-mail system.
> > ***INFOSYS******** End of Disclaimer ********INFOSYS***
> >
>
>

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