I had added spring security code in my workspace for debugging reasons and I suspected that how can a new page be shown when the URL passed to the filter at the server is old. So I put a dummy filter in front of spring security just to print out the URL that is getting intercepted by spring security filter chain.
So now I find that when a JSF forward happens via NavigationHandler then there is no URL that is actually intercepted by the spring filter. What I saw during debugging was not the correct picture. SO I am back at the same problem. The filter for JSF forwards is not getting invoked at all. Regards, Madhav From: Madhav Bhargava > >Yes, I have made the appropriate configuration for spring security filters so >that specially in the case that >you have described below this property will >make sure that the authentication is done again. > >However I do not think that it has anything to do with a stale URL being >passed to the filter at the server >side. I can understand that the browser >will have an old URL but at the server side the URL intercepted by the >filter >should not be stale. Moreover the control is being forwarded to the correct >page and the page is visible >as well so do not know how can a old ULR be >passed at the server side and a new page be displayed at the client >side. > >Thanks, >Madhav > >From: Michael Kurz [mailto:michi.k...@gmx.at] > >Hm, I thought the same first but he has attribute once-per-request set >to false: > ><security:http once-per-request="false"...> > >- Michael > >Jakob Korherr schrieb: > Hi Madhav, > > I now know what the problem is. I wrote a small test webapp and came to the > following conclusion: > > JSF uses RequestDispatcher.forward(..) to render the second view. Thus the > filter should be invoked for the forward. However, the filter is/was already > invoked for the first request and it cannot be invoked twice for one > request. > > Only for test reasons, remove <dispatcher>REQUEST</dispatcher> from your > filter config in the web.xml and the filter will be invoked for > RequestDispatcher.forward(..), because it was not invoked for the original > request. > > I know this does not solve your problem, but I think there is maybe a > workaround for this.. I myself just don't know one.. > Maybe define the filter twice would solve the problem, but that's just a > guess. > > Regards, > Jakob > > 2010/1/12 Madhav Bhargava <madhav_bharg...@infosys.com> > >> >> -----Original Message----- >> From: Michael Kurz [mailto:michi.k...@gmx.at] >> >>> Madhav Bhargava schrieb: >>> To add if you see the spring security application config, I have the >> following set: >>> <security:http> >>> <security:intercept-url pattern="/**/secure/**" >> access="ROLE_USER" /> >>> <security:intercept-url pattern="/**/operations/**" >> access="ROLE_OPERATIONS"/> >>> </security:http> >>> >>> The URL for the outcome to be forwarded to matches the second interceptor >> pattern which is "/jsp/operations/user/operationsLanding.iface" >>> However what the filter receives is "/jsp/secure/hprelanding.jspx" which >> is the old URL from where the control is being forwarded. This is not how it >> happens when using jsp:forward. >> >>> For clarification: Is the navigation to the new page >>> operationsLanding.iface performed (do you actually see it in the browser)? >>> >>> - Michael >> Yes,the request is properly forwarded to operationsLanding.jspx and I can >> view the page. I had put a breakpoint in one of the spring security classes >> and I could see the old URL which got successfully mapped against pattern >> /**/secure/** which should not have happened. >> >> If I have a normal JSP application where there is no JSF then it works >> fine. I meant the navigation is not handled by JSF. >> >> 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***
