yeah basicly each page a user can see that you want to protect would have some kind of unique identifier...maybe a name, maybe a number. Lets say you had an order form which had 3 steps.
The user starts the process and it shows them the first page and does something like this: <@assign user$CurrentPage value="order1"> then on this form they fill out the info and can hit "next". This sends them to part of the taf for step 2. before it shows any html or processes anything for step 2, it checks to make sure @@user$CurrentPage=order1. If it doesnt, it can show them the "warning this page has expired" message, or send them back to the main menu, or whatever you want. If it does, show them the 2nd step and do one of these: <@assign user$CurrentPage value="order2"> the user fills out info, clicks next, and they get sent to the code for step 3. Step 3 checks to make sure @@user$CurrentPage=order2. If not shows error, if so shows form. There are some details to work out, but this should be enough to get something started (: ----- Original Message ----- From: "Steve Campbell" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, February 24, 2003 10:38 AM Subject: Re: WiTango-Talk: overcoming the browser back button > So.. > If am following.. > > <@ASSIGN NAME="myname" SCOPE=USER VALUE="<@VAR lastpagehit>"> > > Is this what you are suggestioning? > > Steve > > On 2/24/03 12:35 PM, "Rick Sanders" <[EMAIL PROTECTED]> wrote: > > > I was just about to suggest that. > > > > Assign a variable at the next page. If the person goes back and re-submits, > > the variable was already assigned, so you can throw whatever error or > > message you want. > > > > Rick Sanders > > > > ----- Original Message ----- > > From: "Atrix Wolfe" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Monday, February 24, 2003 1:32 PM > > Subject: Re: WiTango-Talk: overcoming the browser back button > > > > > >> well i think one way to implement this would be to have a user$ variable > >> which kept track of which screen they were looking at. That way, if they > >> requested a screen which didnt match the screen they should be seeing, it > >> could show them a "warning this page has expired" screen or maybe just > >> redirect them to where they should be. Im not sure if theres an easier > > way, > >> but this way seems pretty simple. > >> > >> > >> ----- Original Message ----- > >> From: "Steve Campbell" <[EMAIL PROTECTED]> > >> To: <[EMAIL PROTECTED]> > >> Sent: Monday, February 24, 2003 10:22 AM > >> Subject: Re: WiTango-Talk: overcoming the browser back button > >> > >> > >>> Great idea Rick...wonder if anyone has ported that over to a taf yet? > >>> > >>> Steve > >>> > >>> > >>> On 2/24/03 12:08 PM, "Rick Sanders" <[EMAIL PROTECTED]> wrote: > >>> > >>>> What about making the page expire like they do on the PayPal website? > >> When > >>>> you click back, you get the page expired message. > >>>> > >>>> Rick Sanders > >>>> > >>>> ----- Original Message ----- > >>>> From: "James MacFarlane" <[EMAIL PROTECTED]> > >>>> To: <[EMAIL PROTECTED]> > >>>> Sent: Monday, February 24, 2003 12:51 PM > >>>> Subject: RE: WiTango-Talk: overcoming the browser back button > >>>> > >>>> > >>>>> In short, there is *NO WAY* to disable the BACK button. > >>>>> > >>>>> One thing you can do is have the form submit itself to a page that > >>>> generates > >>>>> a redirect to the following page. This way if the user presses BACK > >> they > >>>>> will go back to the redirect page, which will send them back forward > >>>> again. > >>>>> > >>>>> This will not stop the user from using HISTORY to go back though. > >>>>> > >>>>> Another technique is to use a hidden frameset to store some 'page > >> state' > >>>>> variable. Whenever a page loads, you can have it run a javascript > >> function > >>>>> in the hidden frame. When page TWO loads you can have a variable on > > the > >>>>> hidden page set to "2", so if someone goes back to page ONE, the > > script > >> in > >>>>> the hidden frame can detect that they've already been to page TWO and > >> send > >>>>> them back there. > >>>>> > >>>>> There are many things you can do, none of them are 100% fool-proof. > >> These > >>>>> ones should work pretty well though. > >>>>> > >>>>> - James > >>>>> > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: Steve Campbell [mailto:[EMAIL PROTECTED] > >>>>> Sent: Monday, February 24, 2003 12:19 PM > >>>>> To: [EMAIL PROTECTED] > >>>>> Subject: Re: WiTango-Talk: overcoming the browser back button > >>>>> > >>>>> The mail action is fixed...the logs showed that I relayed myself > >> out..so > >>>> the > >>>>> idea to que is a good one..and iss now working. > >>>>> > >>>>> Now on to the next problem. > >>>>> > >>>>> I have a simple form entry, that checks against a few columns to > > make > >>>> sure > >>>>> the user has entered data in the form already. I am only allowing the > >> user > >>>>> to enter once. > >>>>> > >>>>> I have found that hitting the "browswer back" button that they can > > keep > >>>>> entereing. > >>>>> > >>>>> Anyway around this? > >>>>> > >>>>> > >>>>> Steve > >>>>> > >>>>> Thanks for eveyrthing guys.. > >>>>> > >>>>> > >>>>> > >> ________________________________________________________________________ > >>>>> TO UNSUBSCRIBE: send a plain text/US ASCII email to > >> [EMAIL PROTECTED] > >>>>> with unsubscribe witango-talk in the message body > >>>>> > >>>>> > >> ________________________________________________________________________ > >>>>> TO UNSUBSCRIBE: send a plain text/US ASCII email to > >> [EMAIL PROTECTED] > >>>>> with unsubscribe witango-talk in the message body > >>>>> > >>>> > >>>> > >>>> > > ________________________________________________________________________ > >>>> TO UNSUBSCRIBE: send a plain text/US ASCII email to > > [EMAIL PROTECTED] > >>>> with unsubscribe witango-talk in the message body > >>> > >>> > >>> ________________________________________________________________________ > >>> TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] > >>> with unsubscribe witango-talk in the message body > >> > >> ________________________________________________________________________ > >> TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] > >> with unsubscribe witango-talk in the message body > >> > > > > > > ________________________________________________________________________ > > TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] > > with unsubscribe witango-talk in the message body > > > ________________________________________________________________________ > TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] > with unsubscribe witango-talk in the message body ________________________________________________________________________ TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] with unsubscribe witango-talk in the message body
