You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Jeff Smith <je...@centralscheduling.net> on 2003/03/07 08:25:24 UTC
Avoiding refresh stomping
I worry about users. I've been one. I know how unpredictable we can be. :-)
Take this case. I have a struts app and I want users to be able to log in. Pretty simple. In fact, it is probably the most common scenario implemented in samples and tutorials.
Being a good host, I like to keep track of my guests. So when my users log in, I want to time-stamp them so I know how long they've been connected.
My action-forward for login success takes me to a pretty page that gives my users stats about their last logon (in case somebody is using their account without their knowledge) and a bunch of other stuff.
So they tend to sit on that page and read it for a while.
Then (and here's the unpredictable user part) for some reason, they hit the refresh button on their browser. Well, since they got here as an action forward from the authentication sequence, the refresh resubmits all their logon credentials, the system re-authenticates them and then takes them, finally, back to the page they've been reading and refreshes it. And in that process, my login timestamp is stomped with a newer one.
Now, I have already figured out a few ways to short circuit the re-authentication (like, don't authenticate a user who is already logged in.) But the question is, where else could my users be inadvertently causing spurious recursions into potentially costly sequences by ignorantly hitting the refresh button? I can imagine that some of my action sequences might invoke some fairly expensive computations before displaying the results. But do I *REALLY* want to recompute the whole thing when my users hit refresh? In the case of rendering dynamic content, maybe I do. But for transactional stuff like logging in, or submitting a credit card for authentication, I probably don't want to re-compute on refresh.
Am I the only one who worries about stuff like this?
I want my site to be bullet proof, idiot proof and all-kinds-of-other-things-proof. I'd be curious to know how other people handle this situation.
Jefficus
Re: Avoiding refresh stomping
Posted by Jeff Smith <je...@centralscheduling.net>.
I'm glad you suggested that, because that was the first thing I tried. But
my redirected JSPs don't render properly when I do that - for some reason it
seems to lose track of the style sheet. I wasn't sure if I was
misunderstanding the function of a redirect or if there was a bug somewhere
in my JSP. I'm assuming this is something I've done wrong, but I haven't got
a clue what could be causing it.
Jefficus
----- Original Message -----
From: "Dan Allen" <da...@mojavelinux.com>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>
Sent: Friday, March 07, 2003 12:35 AM
Subject: Re: Avoiding refresh stomping
> > Am I the only one who worries about stuff like this?
> Nope
>
> > Then (and here's the unpredictable user part) for some reason,
> > they hit the refresh button on their browser....
> Here is how to handle this case, and I was actually going to be
> e-mailing the list about this anyway, so glad you brought it up.
>
> You have to "disconnect" the POST data from the current page by
> using a URL redirect. This way, when the user presses refresh, they
> no longer have the POST data available. You probably want to return
> a redirect action forward from your action to make this happen,
> along with any GET data you might need to reconstruct your page.
>
> vBulletin handles this well when you search and post a message,
> except instead of using a server side redirect they use a client
> side meta-refresh. I prefer the server side since the user isn't
> even aware that it is happening.
>
> Dan
>
> --
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Daniel Allen, <da...@mojavelinux.com>
> http://www.mojavelinux.com/
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> "I'm old enough to know better, but still too young to care."
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Avoiding refresh stomping
Posted by Dan Allen <da...@mojavelinux.com>.
> Am I the only one who worries about stuff like this?
Nope
> Then (and here's the unpredictable user part) for some reason,
> they hit the refresh button on their browser....
Here is how to handle this case, and I was actually going to be
e-mailing the list about this anyway, so glad you brought it up.
You have to "disconnect" the POST data from the current page by
using a URL redirect. This way, when the user presses refresh, they
no longer have the POST data available. You probably want to return
a redirect action forward from your action to make this happen,
along with any GET data you might need to reconstruct your page.
vBulletin handles this well when you search and post a message,
except instead of using a server side redirect they use a client
side meta-refresh. I prefer the server side since the user isn't
even aware that it is happening.
Dan
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Daniel Allen, <da...@mojavelinux.com>
http://www.mojavelinux.com/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"I'm old enough to know better, but still too young to care."
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Avoiding refresh stomping
Posted by Mark <st...@webpit.com>.
I've resolved this type of problem by using a redirect instead. This way, if they refresh, they only refresh the current page (which should just render a view, not process any business logic).
It also depends on where you have your business logic.
Regards,
Mark
*********** REPLY SEPARATOR ***********
On 03/07/2003 at 12:25 AM Jeff Smith wrote:
>I worry about users. I've been one. I know how unpredictable we can be. :-)
>
>Take this case. I have a struts app and I want users to be able to log in. Pretty simple. In fact, it is probably the most common scenario implemented in samples and tutorials.
>
>Being a good host, I like to keep track of my guests. So when my users log in, I want to time-stamp them so I know how long they've been connected.
>
>My action-forward for login success takes me to a pretty page that gives my users stats about their last logon (in case somebody is using their account without their knowledge) and a bunch of other stuff.
>
>So they tend to sit on that page and read it for a while.
>
>Then (and here's the unpredictable user part) for some reason, they hit the refresh button on their browser. Well, since they got here as an action forward from the authentication sequence, the refresh resubmits all their logon credentials, the system re-authenticates them and then takes them, finally, back to the page they've been reading and refreshes it. And in that process, my login timestamp is stomped with a newer one.
>
>Now, I have already figured out a few ways to short circuit the re-authentication (like, don't authenticate a user who is already logged in.) But the question is, where else could my users be inadvertently causing spurious recursions into potentially costly sequences by ignorantly hitting the refresh button? I can imagine that some of my action sequences might invoke some fairly expensive computations before displaying the results. But do I *REALLY* want to recompute the whole thing when my users hit refresh? In the case of rendering dynamic content, maybe I do. But for transactional stuff like logging in, or submitting a credit card for authentication, I probably don't want to re-compute on refresh.
>
>Am I the only one who worries about stuff like this?
>
>I want my site to be bullet proof, idiot proof and all-kinds-of-other-things-proof. I'd be curious to know how other people handle this situation.
>
>
>Jefficus
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Nested Iterate Proerty value in a hidden field
Posted by ashokd <as...@visualsoft-tech.com>.
Hi,
How to capture a nested iterate property value into a hidden field. I am
displaying only one record depending upon the condition, At this time i wan
to captrue some values into a hidden fields. How can we do this?
Thanks & Regards,
Ashok.D
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: Avoiding refresh stomping
Posted by Andrew Hill <an...@gridnode.com>.
Another problem I encountered with going direct from a post instead of
redirecting is that all the submitted parameters are carried along too -
which means that data submitted for form A can end up populating fields on
action form B where the parameter names match...
...handling the back button gracefully can be very difficult - especially if
many of your GETs are more in the nature of state-changing events rather
than navigational requests. (Of course its better to use posts for such, but
its not always practical)
-----Original Message-----
From: Max Cooper [mailto:max@maxcooper.com]
Sent: Friday, 7 March 2003 16:10
To: Struts Users Mailing List; andrew.david.hill@gridnode.com
Subject: Re: Avoiding refresh stomping
Dan's suggestion to use redirects is a good one. I redirect in response to
most POST operations to avoid these problems. It adds a bit of network
overhead to some of the pages, but the exipred POST data, double submits,
and the browser's address bar not matching what the user is seeing are all
worse, in my opinion. Bookmarking the page after a POST is another
troublesome area, so redirecting (which always results in the browser making
a GET request) solves a lot of those problems.
> Its not just refreshes you need to worry about. The back button is
> particularly dangerous in this regard!
Oh yes, the Back button is a problem, too. I reject the idea that you can
tell users not to use it -- that just isn't a reasonable position. But
handling it properly is admittedly a big challenge. Most browsers will drop
the POST request from the history since the response is a redirect, which
seems to work out perfectly most of the time.
> First thing you want to look at is the "transaction token" stuff in
struts.
That is a wise additional measure to take.
> This is designed to detect multiple requests of the nature you describe -
> especially users clicking submit multiple times (which they tend to do on
> any submit that takes more than about half a second!!!!)
In watching people (even ones who should know better) I find that an
alarming number of users double-click everything. Links, submit buttons, you
name it -- people double click them all the time. I guess they just like to
show off their double-clicking prowess or something.
-Max
> -----Original Message-----
> From: Jeff Smith [mailto:jeffs@centralscheduling.net]
> Sent: Friday, 7 March 2003 15:25
> To: Struts Users Mailing List
> Subject: Avoiding refresh stomping
>
>
> I worry about users. I've been one. I know how unpredictable we can be.
:-)
>
> Take this case. I have a struts app and I want users to be able to log in.
> Pretty simple. In fact, it is probably the most common scenario
implemented
> in samples and tutorials.
>
> Being a good host, I like to keep track of my guests. So when my users log
> in, I want to time-stamp them so I know how long they've been connected.
>
> My action-forward for login success takes me to a pretty page that gives
my
> users stats about their last logon (in case somebody is using their
account
> without their knowledge) and a bunch of other stuff.
>
> So they tend to sit on that page and read it for a while.
>
> Then (and here's the unpredictable user part) for some reason, they hit
the
> refresh button on their browser. Well, since they got here as an action
> forward from the authentication sequence, the refresh resubmits all their
> logon credentials, the system re-authenticates them and then takes them,
> finally, back to the page they've been reading and refreshes it. And in
that
> process, my login timestamp is stomped with a newer one.
>
> Now, I have already figured out a few ways to short circuit the
> re-authentication (like, don't authenticate a user who is already logged
> in.) But the question is, where else could my users be inadvertently
causing
> spurious recursions into potentially costly sequences by ignorantly
hitting
> the refresh button? I can imagine that some of my action sequences might
> invoke some fairly expensive computations before displaying the results.
But
> do I *REALLY* want to recompute the whole thing when my users hit refresh?
> In the case of rendering dynamic content, maybe I do. But for
transactional
> stuff like logging in, or submitting a credit card for authentication, I
> probably don't want to re-compute on refresh.
>
> Am I the only one who worries about stuff like this?
>
> I want my site to be bullet proof, idiot proof and
> all-kinds-of-other-things-proof. I'd be curious to know how other people
> handle this situation.
>
>
> Jefficus
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Avoiding refresh stomping
Posted by Max Cooper <ma...@maxcooper.com>.
Dan's suggestion to use redirects is a good one. I redirect in response to
most POST operations to avoid these problems. It adds a bit of network
overhead to some of the pages, but the exipred POST data, double submits,
and the browser's address bar not matching what the user is seeing are all
worse, in my opinion. Bookmarking the page after a POST is another
troublesome area, so redirecting (which always results in the browser making
a GET request) solves a lot of those problems.
> Its not just refreshes you need to worry about. The back button is
> particularly dangerous in this regard!
Oh yes, the Back button is a problem, too. I reject the idea that you can
tell users not to use it -- that just isn't a reasonable position. But
handling it properly is admittedly a big challenge. Most browsers will drop
the POST request from the history since the response is a redirect, which
seems to work out perfectly most of the time.
> First thing you want to look at is the "transaction token" stuff in
struts.
That is a wise additional measure to take.
> This is designed to detect multiple requests of the nature you describe -
> especially users clicking submit multiple times (which they tend to do on
> any submit that takes more than about half a second!!!!)
In watching people (even ones who should know better) I find that an
alarming number of users double-click everything. Links, submit buttons, you
name it -- people double click them all the time. I guess they just like to
show off their double-clicking prowess or something.
-Max
> -----Original Message-----
> From: Jeff Smith [mailto:jeffs@centralscheduling.net]
> Sent: Friday, 7 March 2003 15:25
> To: Struts Users Mailing List
> Subject: Avoiding refresh stomping
>
>
> I worry about users. I've been one. I know how unpredictable we can be.
:-)
>
> Take this case. I have a struts app and I want users to be able to log in.
> Pretty simple. In fact, it is probably the most common scenario
implemented
> in samples and tutorials.
>
> Being a good host, I like to keep track of my guests. So when my users log
> in, I want to time-stamp them so I know how long they've been connected.
>
> My action-forward for login success takes me to a pretty page that gives
my
> users stats about their last logon (in case somebody is using their
account
> without their knowledge) and a bunch of other stuff.
>
> So they tend to sit on that page and read it for a while.
>
> Then (and here's the unpredictable user part) for some reason, they hit
the
> refresh button on their browser. Well, since they got here as an action
> forward from the authentication sequence, the refresh resubmits all their
> logon credentials, the system re-authenticates them and then takes them,
> finally, back to the page they've been reading and refreshes it. And in
that
> process, my login timestamp is stomped with a newer one.
>
> Now, I have already figured out a few ways to short circuit the
> re-authentication (like, don't authenticate a user who is already logged
> in.) But the question is, where else could my users be inadvertently
causing
> spurious recursions into potentially costly sequences by ignorantly
hitting
> the refresh button? I can imagine that some of my action sequences might
> invoke some fairly expensive computations before displaying the results.
But
> do I *REALLY* want to recompute the whole thing when my users hit refresh?
> In the case of rendering dynamic content, maybe I do. But for
transactional
> stuff like logging in, or submitting a credit card for authentication, I
> probably don't want to re-compute on refresh.
>
> Am I the only one who worries about stuff like this?
>
> I want my site to be bullet proof, idiot proof and
> all-kinds-of-other-things-proof. I'd be curious to know how other people
> handle this situation.
>
>
> Jefficus
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: Avoiding refresh stomping
Posted by Andrew Hill <an...@gridnode.com>.
Its not just refreshes you need to worry about. The back button is
particularly dangerous in this regard!
First thing you want to look at is the "transaction token" stuff in struts.
This is designed to detect multiple requests of the nature you describe -
especially users clicking submit multiple times (which they tend to do on
any submit that takes more than about half a second!!!!)
I havent really had a chance to look into it much myself (yet!) so cant
really advise further on the technical details.
-----Original Message-----
From: Jeff Smith [mailto:jeffs@centralscheduling.net]
Sent: Friday, 7 March 2003 15:25
To: Struts Users Mailing List
Subject: Avoiding refresh stomping
I worry about users. I've been one. I know how unpredictable we can be. :-)
Take this case. I have a struts app and I want users to be able to log in.
Pretty simple. In fact, it is probably the most common scenario implemented
in samples and tutorials.
Being a good host, I like to keep track of my guests. So when my users log
in, I want to time-stamp them so I know how long they've been connected.
My action-forward for login success takes me to a pretty page that gives my
users stats about their last logon (in case somebody is using their account
without their knowledge) and a bunch of other stuff.
So they tend to sit on that page and read it for a while.
Then (and here's the unpredictable user part) for some reason, they hit the
refresh button on their browser. Well, since they got here as an action
forward from the authentication sequence, the refresh resubmits all their
logon credentials, the system re-authenticates them and then takes them,
finally, back to the page they've been reading and refreshes it. And in that
process, my login timestamp is stomped with a newer one.
Now, I have already figured out a few ways to short circuit the
re-authentication (like, don't authenticate a user who is already logged
in.) But the question is, where else could my users be inadvertently causing
spurious recursions into potentially costly sequences by ignorantly hitting
the refresh button? I can imagine that some of my action sequences might
invoke some fairly expensive computations before displaying the results. But
do I *REALLY* want to recompute the whole thing when my users hit refresh?
In the case of rendering dynamic content, maybe I do. But for transactional
stuff like logging in, or submitting a credit card for authentication, I
probably don't want to re-compute on refresh.
Am I the only one who worries about stuff like this?
I want my site to be bullet proof, idiot proof and
all-kinds-of-other-things-proof. I'd be curious to know how other people
handle this situation.
Jefficus
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org