Re: New twist on old topic? Back button issue with Token

[Jason King]

Using the token does account for the user hitting the back button.   
Having been building web apps for almost 10 years now, I'm very much of 
the back button is evil school.  If there's an element on the page that 
allows going to the beginning of the workflow and token is used to 
prevent accidental double-submits then if the common use-case was that 
lots of the information was repeated from page to page then that link 
would call an action that repopulated the form rather than starting empty. 
Changing one thing makes it a new submit sounds like a bug that we 
literally spent years dealing with of a payment system that if the user 
entered the wrong amount s/he would just "back button" to the payment 
page again and change the amount.  This played hobb with our credit card 
processing system because people were getting charged for both amounts 
and the back + resubmit eliminated the data on the first submit. 
Chris Pratt wrote:
I don't know if I agree with your last statement.  I often prefer to 
use the
back button rather than buttons that are on the screen right in front 
of my
face, so it's often much less about site design and more about user
preference.  But not accounting for someone using the back button, that
would be poor design.
 (*Chris*)
On 10/4/06, Jason King <[EMAIL PROTECTED]> wrote:

If the user has a workflow that involves cycling back, give them a link
or button to cycle back with.  If the users need to use the back button
as a regular part of their use of the application the application is
poorly designed.
Chris Pratt wrote:
> How about basing the value of the tag on some computed value involving
> the
> data in question (like adding up all the hashcodes and using that 
as the
> token value).  Then if the data changes, it's a different token?
>  (*Chris*)
>
> On 10/4/06, pantichd <[EMAIL PROTECTED]> wrote:
>>
>>
>> Hello,
>>
>> Forgive me for bringing up what seems to be a topic that's been
>> discussed
>> here a lot: Issues with the back button.
>>
>> I am using the token mechanism to prevent multiple form submits.
>>
>> My jsp is invoked with a ForwardAction where I set the token.
>>
>> The jsp submits to an action that checks if the token is valid. So
>> far, so
>> good. That works like a charm.
>>
>> The problem, as is extensively pointed out in documentation
>> everywhere, is
>> that there is nothing to prevent the user from hitting the browser 
back
>> button and submitting the form again. If the user hasn't changed
>> anything
>> on
>> the form then the resulting behavior (action class rejects the submit
>> because the token isn't valid anymore) is exactly what I want.
>>
>> Where this scenario falls apart, though, is if the user changes 
some of
>> the
>> values on the form before submitting the form again. At this 
point, the
>> logical thing (at least in the user's mind) is that the submit should
be
>> accepted. However, the action will still think the token is invalid
>> (because
>> it was never reset by the ForwardAction) and will therefore reject 
the
>> submittal.
>>
>> OK, I understand why/how all this happens. My question is, how are
>> others
>> dealing with this?
>>
>> This is a pretty basic scenario that I'm sure anyone who has done
Struts
>> development has run into. What are some of the solutions you've 
come up
>> with?
>>
>> I know I can put some text on the page(s) warning user NOT to use the
>> back
>> button but there is no guarantee that they'll pay attention.
>>
>> I can also put some script that sets some hidden field value whenever
>> any
>> input field on the form changes. However, that will kind of conflict
>> with
>> the token mechanism and maybe even eliminate the need for the token
>> mechanism. The problem with that is ... what if user has Java Script
>> turned
>> off.
>>
>> Any feedback will be appreciated.
>> --
>> View this message in context:
>>
http://www.nabble.com/New-twist-on-old-topic--Back-button-issue-with-Token-tf2382440.html#a6639844 

>>
>> Sent from the Struts - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> 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]