method to protect webapps from users

[pe...@granada-learning.com]

hi guys,

I'm new to this list, but a long time user of Tomcat.  For a long time now
I've had a problem which I'm sure most of you are familiar with ; users.

As always happens with any app in development the final tidy up stuff gets
left too late and some stuff gets missed out.  The bit in this case was
holding screens for long running requests.

I've written a filter which will take any request and after a defined
period of time send a generic "please wait" page, after the original
request has finished it will then forward the proper response.

To get this to work properly there is an extra benefit, it can in a lot of
cases stop double clickers by ignoring requests that have been defined as
those not supposed to run concurrently for a given session.

My current implemntation is container agnostic which I'm not really happy
with as it means the "please wait" page must be large enough to force a
send of the data though the response stream, however I'm loathe to hack
into the tomcat code to get low enough to fix this unless it is part of
tomcat.  The second problem is detecting multi-part requests and not
allowing the "please wait" page until the multi-part data has been
gathered, currently I just exclude those requests, again a lower level
access would allow this to be fixed properly.

Is this filter or a derivative something that would be of interest?

The basic features that I've implemented are :

please wait page after some defined period with no user coding
Multiple concurrent request per session selectively disabled by URL

I can post the code or distribute however people want if this is something
you are interested in.

In live web-apps I've found this invaluable as users don't get web-apps
and are very impatient, even if the problem is their dodgy old modem or
asking an app to do something it was never designed for.

Before anyone says it I know this is a complete perversion of everything
that is supposed to happen in a web-app, however in the real world users
won't wait 5 seconds for anything unless they are being told it's under
way and I've never got holding screens in all the right places yet.  This
covers them all and where possible reduces the ability of a single user to
submit 100 concurrent requests by hammering a submit button in
frustration.

Any feed back is most welcome

Thanks

Peter Mengell

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Re: method to protect webapps from users

[pe...@granada-learning.com]

Thanks for the guidance Rémy, this is why I'm posting to this list, I just
want something in the base build that includes this functionality, so
whatever it takes is fine by me :D

Pete

> peterm@granada-learning.com wrote:
>
>>hi guys,
>>
>>I'm new to this list, but a long time user of Tomcat.  For a long time
>> now
>>I've had a problem which I'm sure most of you are familiar with ; users.
>>
>>As always happens with any app in development the final tidy up stuff
>> gets
>>left too late and some stuff gets missed out.  The bit in this case was
>>holding screens for long running requests.
>>
>>I've written a filter which will take any request and after a defined
>>period of time send a generic "please wait" page, after the original
>>request has finished it will then forward the proper response.
>>
>>To get this to work properly there is an extra benefit, it can in a lot
>> of
>>cases stop double clickers by ignoring requests that have been defined as
>>those not supposed to run concurrently for a given session.
>>
>>My current implemntation is container agnostic which I'm not really happy
>>with as it means the "please wait" page must be large enough to force a
>>send of the data though the response stream, however I'm loathe to hack
>>into the tomcat code to get low enough to fix this unless it is part of
>>tomcat.  The second problem is detecting multi-part requests and not
>>allowing the "please wait" page until the multi-part data has been
>>gathered, currently I just exclude those requests, again a lower level
>>access would allow this to be fixed properly.
>>
>>Is this filter or a derivative something that would be of interest?
>>
>>The basic features that I've implemented are :
>>
>>please wait page after some defined period with no user coding
>>Multiple concurrent request per session selectively disabled by URL
>>
>>I can post the code or distribute however people want if this is
>> something
>>you are interested in.
>>
>>In live web-apps I've found this invaluable as users don't get web-apps
>>and are very impatient, even if the problem is their dodgy old modem or
>>asking an app to do something it was never designed for.
>>
>>Before anyone says it I know this is a complete perversion of everything
>>that is supposed to happen in a web-app, however in the real world users
>>won't wait 5 seconds for anything unless they are being told it's under
>>way and I've never got holding screens in all the right places yet.  This
>>covers them all and where possible reduces the ability of a single user
>> to
>>submit 100 concurrent requests by hammering a submit button in
>>frustration.
>>
>>Any feed back is most welcome
>>
>>
> This is not necessarily evil. Of course, I don't know if it's good or
> not before seeing the code first.
>
> Note: if a filter needs internal access to Tomcat APIs, then it should
> likely become a valve.
>
> Rémy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Re: method to protect webapps from users

[Remy Maucherat <re...@apache.org>]

peterm@granada-learning.com wrote:

>hi guys,
>
>I'm new to this list, but a long time user of Tomcat.  For a long time now
>I've had a problem which I'm sure most of you are familiar with ; users.
>
>As always happens with any app in development the final tidy up stuff gets
>left too late and some stuff gets missed out.  The bit in this case was
>holding screens for long running requests.
>
>I've written a filter which will take any request and after a defined
>period of time send a generic "please wait" page, after the original
>request has finished it will then forward the proper response.
>
>To get this to work properly there is an extra benefit, it can in a lot of
>cases stop double clickers by ignoring requests that have been defined as
>those not supposed to run concurrently for a given session.
>
>My current implemntation is container agnostic which I'm not really happy
>with as it means the "please wait" page must be large enough to force a
>send of the data though the response stream, however I'm loathe to hack
>into the tomcat code to get low enough to fix this unless it is part of
>tomcat.  The second problem is detecting multi-part requests and not
>allowing the "please wait" page until the multi-part data has been
>gathered, currently I just exclude those requests, again a lower level
>access would allow this to be fixed properly.
>
>Is this filter or a derivative something that would be of interest?
>
>The basic features that I've implemented are :
>
>please wait page after some defined period with no user coding
>Multiple concurrent request per session selectively disabled by URL
>
>I can post the code or distribute however people want if this is something
>you are interested in.
>
>In live web-apps I've found this invaluable as users don't get web-apps
>and are very impatient, even if the problem is their dodgy old modem or
>asking an app to do something it was never designed for.
>
>Before anyone says it I know this is a complete perversion of everything
>that is supposed to happen in a web-app, however in the real world users
>won't wait 5 seconds for anything unless they are being told it's under
>way and I've never got holding screens in all the right places yet.  This
>covers them all and where possible reduces the ability of a single user to
>submit 100 concurrent requests by hammering a submit button in
>frustration.
>
>Any feed back is most welcome
>  
>
This is not necessarily evil. Of course, I don't know if it's good or 
not before seeing the code first.

Note: if a filter needs internal access to Tomcat APIs, then it should 
likely become a valve.

Rémy


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Re: method to protect webapps from users

[Rick Knowles <ri...@knowleses.org>]

Peter,

Is there anything you're doing with the request / response objects that 
you couldn't do with Request/ResponseWrappers ? You could have your 
filter populate a Request / Response Wrapper pair on the first request, 
and then set the wrapper's request object to the second request when it 
comes in. The effect would be that the second request could mimic the 
first if you override the wrapper's methods to return the values from 
the first request instead of the second.

Note this is just another suggested option, with a view to preserving 
the container agnosticism - personally I think container agnosticism is 
a huge advantage, and I'd suggest trying to preserve it in your code if 
you can. Don't make it container specific unless you absolutely have no 
choice.

There's a lot you can do with wrappers and faked input/output streams to 
achieve the kind of goals you mentioned without tying it to a container. 
I'll leave it for you to decide whether it's a better design choice or 
not - no doubt others on this list would disagree with the above 
approach, but I had to at least offer it.

Rick

-- 
Servlet v2.4 container in a single 140KB jar file ? Try Winstone (http://winstone.sf.net/)


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Re: method to protect webapps from users

[pe...@granada-learning.com]

Hi Tim,

Currently it is only using servlet spec stuff, but this imposes a few
limitations and some extra resource usage, if it became a valve in tomcat
it could remove these limitations and extra resource burdens.

For this reason I was seeking approval from those involved with the tomcat
dev work before I convert it.  If people are fundamentally against the
feature set or have a good technical reason for it being done differently
or not done I am happy to listen.

If it becomes a valve then the extra request/response object it holds on
to can be recycled, the number of active threads should be reducable to 1
java thread per request instead of up to 2 per request, which is quite
important for Linux users.

As a valve with access to the real request object it can also deal with
multi-part requests correctly and postpone the wait page until it is safe
to deliver and will be able to flush the buffers to cause a much smaller
wait page to be sent.

The thing I am most keen for is that it or some alernative code that does
the same is taken up and maintained as I have found no generic
application-transparent implementations of a busy page or don't press that
button again functionality.

Pete

> If your using Servlet spec features only - move this to tomcat-user. As
> for
> including the functionality in tomcat, my preference is no since it is not
> tomcat specific and can be used by any container. If thats the case - it
> might be better as a Sourceforge project. ... Unless we create a
> subproject
> under tomcat for contributions such as utilities, alternative OS startup
> scripts, etc (But not make it prt of the default distribution)
>
> -Tim
>
> peterm@granada-learning.com wrote:
>
>> hi guys,
>>
>> I'm new to this list, but a long time user of Tomcat.  For a long time
>> now
>> I've had a problem which I'm sure most of you are familiar with ; users.
>>
>> As always happens with any app in development the final tidy up stuff
>> gets
>> left too late and some stuff gets missed out.  The bit in this case was
>> holding screens for long running requests.
>>
>> I've written a filter which will take any request and after a defined
>> period of time send a generic "please wait" page, after the original
>> request has finished it will then forward the proper response.
>>
>> To get this to work properly there is an extra benefit, it can in a lot
>> of
>> cases stop double clickers by ignoring requests that have been defined
>> as
>> those not supposed to run concurrently for a given session.
>>
>> My current implemntation is container agnostic which I'm not really
>> happy
>> with as it means the "please wait" page must be large enough to force a
>> send of the data though the response stream, however I'm loathe to hack
>> into the tomcat code to get low enough to fix this unless it is part of
>> tomcat.  The second problem is detecting multi-part requests and not
>> allowing the "please wait" page until the multi-part data has been
>> gathered, currently I just exclude those requests, again a lower level
>> access would allow this to be fixed properly.
>>
>> Is this filter or a derivative something that would be of interest?
>>
>> The basic features that I've implemented are :
>>
>> please wait page after some defined period with no user coding
>> Multiple concurrent request per session selectively disabled by URL
>>
>> I can post the code or distribute however people want if this is
>> something
>> you are interested in.
>>
>> In live web-apps I've found this invaluable as users don't get web-apps
>> and are very impatient, even if the problem is their dodgy old modem or
>> asking an app to do something it was never designed for.
>>
>> Before anyone says it I know this is a complete perversion of everything
>> that is supposed to happen in a web-app, however in the real world users
>> won't wait 5 seconds for anything unless they are being told it's under
>> way and I've never got holding screens in all the right places yet.
>> This
>> covers them all and where possible reduces the ability of a single user
>> to
>> submit 100 concurrent requests by hammering a submit button in
>> frustration.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Re: method to protect webapps from users

[Tim Funk <fu...@joedog.org>]

If your using Servlet spec features only - move this to tomcat-user. As for 
including the functionality in tomcat, my preference is no since it is not 
tomcat specific and can be used by any container. If thats the case - it 
might be better as a Sourceforge project. ... Unless we create a subproject 
under tomcat for contributions such as utilities, alternative OS startup 
scripts, etc (But not make it prt of the default distribution)

-Tim

peterm@granada-learning.com wrote:

> hi guys,
> 
> I'm new to this list, but a long time user of Tomcat.  For a long time now
> I've had a problem which I'm sure most of you are familiar with ; users.
> 
> As always happens with any app in development the final tidy up stuff gets
> left too late and some stuff gets missed out.  The bit in this case was
> holding screens for long running requests.
> 
> I've written a filter which will take any request and after a defined
> period of time send a generic "please wait" page, after the original
> request has finished it will then forward the proper response.
> 
> To get this to work properly there is an extra benefit, it can in a lot of
> cases stop double clickers by ignoring requests that have been defined as
> those not supposed to run concurrently for a given session.
> 
> My current implemntation is container agnostic which I'm not really happy
> with as it means the "please wait" page must be large enough to force a
> send of the data though the response stream, however I'm loathe to hack
> into the tomcat code to get low enough to fix this unless it is part of
> tomcat.  The second problem is detecting multi-part requests and not
> allowing the "please wait" page until the multi-part data has been
> gathered, currently I just exclude those requests, again a lower level
> access would allow this to be fixed properly.
> 
> Is this filter or a derivative something that would be of interest?
> 
> The basic features that I've implemented are :
> 
> please wait page after some defined period with no user coding
> Multiple concurrent request per session selectively disabled by URL
> 
> I can post the code or distribute however people want if this is something
> you are interested in.
> 
> In live web-apps I've found this invaluable as users don't get web-apps
> and are very impatient, even if the problem is their dodgy old modem or
> asking an app to do something it was never designed for.
> 
> Before anyone says it I know this is a complete perversion of everything
> that is supposed to happen in a web-app, however in the real world users
> won't wait 5 seconds for anything unless they are being told it's under
> way and I've never got holding screens in all the right places yet.  This
> covers them all and where possible reduces the ability of a single user to
> submit 100 concurrent requests by hammering a submit button in
> frustration.
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Re: method to protect webapps from users

[Dakota Jack <cr...@gmail.com>]

I definitely would be interested in seeing this code, although I am
not sure what your question is.  Maybe seeing the code will clear this
up.

Jack


On Wed, 27 Oct 2004 09:23:01 +0100 (BST), peterm@granada-learning.com
<pe...@granada-learning.com> wrote:
> hi guys,
> 
> I'm new to this list, but a long time user of Tomcat.  For a long time now
> I've had a problem which I'm sure most of you are familiar with ; users.
> 
> As always happens with any app in development the final tidy up stuff gets
> left too late and some stuff gets missed out.  The bit in this case was
> holding screens for long running requests.
> 
> I've written a filter which will take any request and after a defined
> period of time send a generic "please wait" page, after the original
> request has finished it will then forward the proper response.
> 
> To get this to work properly there is an extra benefit, it can in a lot of
> cases stop double clickers by ignoring requests that have been defined as
> those not supposed to run concurrently for a given session.
> 
> My current implemntation is container agnostic which I'm not really happy
> with as it means the "please wait" page must be large enough to force a
> send of the data though the response stream, however I'm loathe to hack
> into the tomcat code to get low enough to fix this unless it is part of
> tomcat.  The second problem is detecting multi-part requests and not
> allowing the "please wait" page until the multi-part data has been
> gathered, currently I just exclude those requests, again a lower level
> access would allow this to be fixed properly.
> 
> Is this filter or a derivative something that would be of interest?
> 
> The basic features that I've implemented are :
> 
> please wait page after some defined period with no user coding
> Multiple concurrent request per session selectively disabled by URL
> 
> I can post the code or distribute however people want if this is something
> you are interested in.
> 
> In live web-apps I've found this invaluable as users don't get web-apps
> and are very impatient, even if the problem is their dodgy old modem or
> asking an app to do something it was never designed for.
> 
> Before anyone says it I know this is a complete perversion of everything
> that is supposed to happen in a web-app, however in the real world users
> won't wait 5 seconds for anything unless they are being told it's under
> way and I've never got holding screens in all the right places yet.  This
> covers them all and where possible reduces the ability of a single user to
> submit 100 concurrent requests by hammering a submit button in
> frustration.
> 
> Any feed back is most welcome
> 
> Thanks
> 
> Peter Mengell
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> 
> 


-- 
"You can't wake a person who is pretending to be asleep."

~Native Proverb~

"Each man is good in His sight. It is not necessary for eagles to be crows."

~Hunkesni (Sitting Bull), Hunkpapa Sioux~

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org