Agreed, but the problem here is not with people going back to pages they have been to before, but rather going back to actions, which of course resubmits them.
Users think that if I am on a page, and I click a button, and it takes me to another page, that this new page is placed in the history. But that's not what happens - actually the action that resulted in the user ending up at said page ends up in the history. That's what we are trying to avoid. I don't see how a redirect is any more insecure. It would obviously increase traffic per user - and on a high volume site this could be problematic. > -----Original Message----- > From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] > Sent: 18 January 2002 20:07 > To: turbine-dev > Subject: Re: Redirects > > > Pages that you don't want to allow people to use the back button > should have > a Cache header set that prevents the data from being displayed again (and > thus re-executed). > > If you go to almost any major online banking site, they do this. > Not only is > it a security issue, but it also a way to deal with what is effectively a > broken browser issue. > > -jon > > on 1/18/02 9:09 AM, "Gareth Coltman" > <[EMAIL PROTECTED]> wrote: > > > Thank you. Jon - we await a reply! ;) > > > >> -----Original Message----- > >> From: Eric Dobbs [mailto:[EMAIL PROTECTED]] > >> Sent: 18 January 2002 17:04 > >> To: Turbine Developers List > >> Subject: Re: Redirects > >> > >> > >> > >> On Friday, January 18, 2002, at 02:38 AM, Gareth Coltman wrote: > >> > >>> - User logs in. (URL: /Login.vm) > >>> - User clicks on login button (URL: /action/Login) > >>> - Template is set to Homepage.vm (URL would still be /Login.vm) > >>> - User goes elsewhere in the site > >>> - User returns to homepage by using browser's back button. > >>> (Eventually returning user to /action/Login and causing the > action to be > >>> performed again) > >> ... > >>> But imagine if this was a delete action. > >>> > >>> This is why I think a redirect can be useful. > >> > >> Agreed that redirects can be useful. > >> > >> We have several pages where backend processing effects status values > >> displayed on the page. The user hits the refresh button, or in the > >> future we may add a meta tag to periodically refresh. On refresh the > >> actions are re-executed. > >> > >> We started by including logic to detect the session counters (the > >> "recommended" solution) to suppress the redundant action. But users > >> wanted to be able to use their back button and resubmit forms to ease > >> the data entry when adding similar records. From their point of view > >> our webapp was breaking a basic feature of the browser. We replaced > >> the session counter logic with redirects. This protects from > >> redundant entries from refresh (and back buttons as Gareth notes) and > >> allows the a feature of the browser to ease data entry. And added > >> bonus, it made our code just slightly easier to follow. > >> > >> That set of benefits was worth the cost of extra network activity for > >> the redirect. > >> > >> -Eric > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
