True, I definitely wouldn't use my suggested token trick in an eCommerce app to allow resubmitting an order, unless you could back out the old order and put this one in it's place (but even that would be risky). It might be useful to determine if you should show the user a page asking if they would like to place a "SECOND" order with the new information and get confirmation that they understand they will be charged again. (*Chris*)
On 10/4/06, Jason King <[EMAIL PROTECTED]> wrote:
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]
