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]>

Reply via email to