One more: Tried MyFilter in a JSF application which first renders index.jsp, then a commandButton is hit and the action method "forwards" to index2.jsp.
Here is the filter-output of the first request: Filter1 (forward + request) invoked for path /faces/index.jsp Filter1 (forward + request) invoked for path /index.jsp ...and for the second request: Filter1 (forward + request) invoked for path /faces/index.jsp Filter1 (forward + request) invoked for path /index2.jsp So here you can see the original faces request (1st lines, including /faces/) and the rendering forward (2nd lines). This shows that the filter is invoked properly. so your problem is maybe related to spring... 2010/1/12 Jakob Korherr <[email protected]> > I'm really sorry, but there seemed to be some configuration problem with my > local tomcat. The filter _is_ called twice. > > My example: > > web.xml (excerpt): > > <servlet> > <servlet-name>Servlet1</servlet-name> > <servlet-class>at.jakobkorherr.servlets.Servlet1</servlet-class> > </servlet> > <servlet> > <servlet-name>Servlet2</servlet-name> > <servlet-class>at.jakobkorherr.servlets.Servlet2</servlet-class> > </servlet> > <servlet-mapping> > <servlet-name>Servlet1</servlet-name> > <url-pattern>/Servlet1</url-pattern> > </servlet-mapping> > <servlet-mapping> > <servlet-name>Servlet2</servlet-name> > <url-pattern>/Servlet2</url-pattern> > </servlet-mapping> > <filter> > <filter-name>MyFilter</filter-name> > <filter-class>at.jakobkorherr.filter.MyFilter</filter-class> > </filter> > <filter-mapping> > <filter-name>MyFilter</filter-name> > > <url-pattern>/*</url-pattern> > <dispatcher>FORWARD</dispatcher> > <dispatcher>REQUEST</dispatcher> > </filter-mapping> > > Servlet1.java (excerpt): > > public void service(ServletRequest request, ServletResponse response) > throws ServletException, IOException > { > System.out.println("Servlet1"); > request.getRequestDispatcher("/Servlet2").forward(request, > response); > } > > Servlet2.java (excerpt): > > public void service(ServletRequest request, ServletResponse response) > throws ServletException, IOException > { > System.out.println("Servlet2"); > response.getWriter().println("Servlet2"); > } > > MyFilter.java (excerpt): > > public void doFilter(ServletRequest request, ServletResponse response, > FilterChain chain) throws IOException, ServletException > { > System.out.println("Filter1 (forward + request) invoked for path " > + ((HttpServletRequest) request).getServletPath()); > chain.doFilter(request, response); > } > > > When requesting Servlet1, the following output is generated (on the > console): > > Filter1 (forward + request) invoked for path /Servlet1 > Servlet1 > Filter1 (forward + request) invoked for path /Servlet2 > Servlet2 > > So this should function properly. > > > 2010/1/12 Jakob Korherr <[email protected]> > > "The filter for JSF forwards is not getting invoked at all." >> >> That's exactly what I was saying!!!! ...and it does not help you if you >> set <security:http once-per-request="false"...>, because the filter is only >> invoked once anyway. >> >> Madhav's problem is that the Filter itself is only invoked once for the >> request (at the time when the user makes the request), although there is a >> internal forward with the RequestDispatcher. >> >> So the problem is that the same Filter is not invoked twice for one >> request (at first for REQUEST and then for FORWARD). >> >> >> Regards, >> Jakob >> >> >> 2010/1/12 Madhav Bhargava <[email protected]> >> >>> 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:[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 >>> >> >>> > >>> >>> >>> **************** 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*** >>> >> >> >
