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