Yes, setting the dispatcher will work just for ignoring the forwards, it won't work for redirects. You can check for attributes as Paul suggests, but setting the dispatcher seems to be easier if you have a servlet container supporting 2.4.
You'll have to handle redirects in another way though. A simple solution would be to remove the time of the last request from your list if you return a redirect to the user. HTH, Tamas On 3/13/07, Paul Benedict <[EMAIL PROTECTED]> wrote:
There is no technical difference between a user request and a redirect, because the redirect causes a second user request. If you're interested in knowing whether the action is being called as a forward, there are standard request attributes which the Container sets. For a forward it is "javax.servlet.forward.request_uri" and for an include it is "javax.servlet.include.request_uri" Paul Tamas Szabo wrote: > Have a look at the documentation of the "dispatcherType" at > http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd. > > Then you can use dispatcher elements in your filter mappings > ("filter-mappingType" in the same xsd) to fire your filter just for > requests but not for forwards. > > I pressume that by "internal redirects" in your initial mail you mean > forwards. Is this true? > > Hope this helps, > > Tamas > > > On 3/13/07, Pierre Thibaudeau <[EMAIL PROTECTED]> wrote: >> Yes, I believe it is 2.4. >> >> Also: >> Struts 1.3.5 >> Tomcat 6.0.9 >> >> 2007/3/12, Tamas Szabo <[EMAIL PROTECTED]>: >> > >> > Hi, >> > >> > What servlet api are you using? >> > Is it at least 2.4? >> > >> > Tamas >> > >> > >> > On 3/13/07, Pierre Thibaudeau <[EMAIL PROTECTED]> wrote: >> > > I am trying to implement a flood control mechanism to prevent robots >> > > requesting pages after pages at an "inhuman" rate. >> > > >> > > My basic idea is this: >> > > * A FirstInFirstOut List stored in the HttpSession, that records the >> > time of >> > > the user's last 10 requests. >> > > * On each new request, a filter compares the current time with the >> time >> > of >> > > the 10th previous request. If not enough time went by, redirect to a >> > "delay >> > > page" that requires the user to press a "Continue" button. Pipe >> the new >> > > request and its time, and pipe out the 10th previous request. >> > > >> > > The problem with that design: in some cases, one single request from >> > the >> > > user will go through the filters several times because of various >> > possible >> > > internal redirects. But I only want to record the times of the >> requests >> > > coming directly from the user. >> > > >> > > Therefore my question: Is there a simple straightforward way, >> from the >> > > filter's point of view, to distinguish between a request that came >> from >> > > outside (from the user), from an internal request (one that came >> through >> > a >> > > redirection from ActionMapping to ActionMapping)? >> > > >> > >> > --------------------------------------------------------------------- >> > 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] > > --------------------------------------------------------------------- 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]
