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 <[email protected]> > 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: [email protected] > >[mailto:[email protected]<[email protected]>] > 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 <[email protected]> > > > > 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: [email protected] > > >[mailto:[email protected]<[email protected]>] > 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 <[email protected]> > > > > > > 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: [email protected] > > > >[mailto:[email protected]<[email protected]>] > 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 <[email protected]> > > > > > > > > Yeah this is the place. > > > > Back to the problem. I still cannot come up with a workaround :( > > > > > > > > From: [email protected] > > > > [mailto:[email protected]<[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]<[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 > > > > > >> > > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > **************** 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*** > > > >
