On Thu, Jul 10, 2008 at 1:59 PM, Alberto A. Flores <[EMAIL PROTECTED]> wrote: > As far as I know, the servlet spec 2.3 didn't comment much on what to do on > forwards (whether to make forwarded resources pass through the filters as > well or not). Tomcat 4.x assumed you didn't have to, whereas other > containers (e.g. weblogic 8) passed them through. This was fix in servlet > spec 2.4 (Tomcat 5.x) where additional configuration can be made for these > cases (the default is only request, but now you have control over forwards, > includes, errors, etc).
Well this has nothing to do with forwards AFAICS, that fact is the exact same link works sometimes and sometimes it doesn't If I am already logged in and I click the link then I goto the relevant resource depending on role without being required to log in. That seems to work fine. The problem occurs when I click the exact same link from different pages, well sometimes it does and then again sometimes it doesn't. I really can't see why one Http Request should be different from another as far as the filter is concerned. There is a forward going on but that is after the user has been validated and the Login servlet executes, it then forwards the request onto the relevant resource but like I say, the user has already been logged in by them. There is obviously something going on that I am not aware of ... > > Depending on what your JSP is trying to do (target url), you security would > need to address those destinations as well. Also, consider checking WW-2025 > (Struts2 JIRA) as the fix above seems to break in IE7 (not sure why either, > but I know that IE handles HTTP 1.1 in a weird way, so I'm not surprised). Well I read that it breaks in IE 7 but I downloaded that particular piece of nastiness and it works fine for me Thank Mozilla for Firefox :-) > > Also, have you declared a security-role, disabled caching on your JSP, etc, > etc, while testing this problem. It is also possible that you properly > authenticated once and the session never got invalidated and you were always > running on a valid session (cookie based). My roles are all there, everything works perfectly ... sometimes ... it's all very confusing I have to say. Anyway, thanks for the ideas I'll keep hacking away Never had this problem with POJOs, Servlets and jsps :-( rgds lyallex > > Lyallex wrote: >> >> Hello >> >> Tomcat version 5.5.26 >> Struts2 version 2.0.11.1 >> >> I'm trying to understand why, given the following in web.xml requests >> sometimes 'miss out' the Struts2 filter >> >> <filter> >> <filter-name>struts2</filter-name> >> >> <filter-class>org.apache.struts2.dispatcher.FilterDispatcher</filter-class> >> </filter> >> >> <filter-mapping> >> <filter-name>struts2</filter-name> >> <url-pattern>/*</url-pattern> >> </filter-mapping> >> >> >> It appears to really only be an issue with web.xml declarative security >> >> Reading around the various archives it appears that this is a know issue >> when trying to use Struts2 Actions as the target but I'm not trying to do >> that >> I just use a standard jsp. >> >> <odd> >> >> The really odd thing is that the login process works perfectly >> sometimes and sometimes it fails with the (apparently well known) message >> >> The Struts dispatcher cannot be found. >> This is usually caused by using Struts tags without the associated filter >> ... >> >> </odd> >> >> Here's the login config >> >> <login-config> >> <auth-method>FORM</auth-method> >> <realm-name>Form based authentication</realm-name> >> <form-login-config> >> <form-login-page>/login.jsp</form-login-page> >> <form-error-page>/login.jsp</form-error-page> >> </form-login-config> >> </login-config> >> >> Someone, somwhere on my journey through the archives suggested this fix. >> >> <filter-mapping> >> <filter-name>struts2</filter-name> >> <url-pattern>/*</url-pattern> >> <dispatcher>REQUEST</dispatcher> >> <dispatcher>FORWARD</dispatcher> >> </filter-mapping> >> >> It does appear to solve the problem I was just wondering why ? >> >> Is there a definitive resolution to this problem out there somewhere ? >> >> TIA >> >> lyallex >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > -- > > Alberto A. Flores > http://www.linkedin.com/in/aflores > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
