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:[email protected]] > >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 <[email protected]> > >> >> -----Original Message----- >> From: Michael Kurz [mailto:[email protected]] >> >>> 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 >> >
