andy, have you had a look at the PRG pattern? You can see a working example and access its source code here:
http://www.superinterface.com/projects/prgtoolkit.htm You can view the article here: http://www.theserverside.com/articles/content/RedirectAfterGet/article.html HTH Cheers, Ben On Mon, 04 Oct 2004 16:21:12 -0700, Michael McGrady <[EMAIL PROTECTED]> wrote: > Hi, Rick, > > Yes, I know why we use tokens. But, Jim had said that we use the Token > to solve this gentleman's problem which was not true. This gentleman's > problem is that he did not want the client to see the same data when he > used the back button. The Token has nothing to do with that. > > Michael McGrady > > > > Rick Reumann wrote: > > > Michael McGrady wrote the following on 10/4/2004 4:30 PM: > > > >> Jim, this is unrelated to the token mechanism. This happens client > >> side. > >> > >> James Mitchell wrote: > >> > >>>> I think this must be a problem which occurs in many projects? > >>>> > >>> > >>> > >>> > >>> Yes, you are correct. That's why we have the token mechanism. > >>> > > > > Michael, Jim is correct, though. This is the reason we use Tokens. > > Even though the user is seeing a cached version, he/she won't be able > > to "do" anything to corrupt the data since tokens were involved. So > > even if the user uses the browser's back button and sees a cached > > page, submitting it will do nothing. If the user tries to use the back > > button and tries to submit again from there my token message warns > > them they are being an idiot:) - don't hit the button a buch of times, > > don't use browser back button , etc. > > > > > > --------------------------------------------------------------------- > 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]
