Re: New twist on old topic? Back button issue with Token
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]
Re: New twist on old topic? Back button issue with Token
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]
Re: New twist on old topic? Back button issue with Token
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]
Re: New twist on old topic? Back button issue with Token
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*) Interesting! Hadn't thought of that. Have you used this method? Thanks for the reply! -- View this message in context: http://www.nabble.com/New-twist-on-old-topic--Back-button-issue-with-Token-tf2382440.html#a6646822 Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New twist on old topic? Back button issue with Token
Sorry, I haven't, it just seemed to make sense. (*Chris*) On 10/4/06, pantichd [EMAIL PROTECTED] wrote: 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*) Interesting! Hadn't thought of that. Have you used this method? Thanks for the reply! -- View this message in context: http://www.nabble.com/New-twist-on-old-topic--Back-button-issue-with-Token-tf2382440.html#a6646822 Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New twist on old topic? Back button issue with Token
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]
Re: New twist on old topic? Back button issue with Token
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]
