Stale Forms

[John Rivers]

Hello,

This topic has bugged me for years.

The ideal for handling web forms
would be that submitting the form
replaces the browser history's current
url with the url resulting from
the form processing code Response.Redirect url

this can be achieved for links using
client-side dom "location.replace()"

however i can't see a way of doing it
for forms?

i am trying to stop people pressing "back"
and seeing old forms and then clicking submit

although i can easily detect this at the server
and stop any damage etc. the perfect solution
would be to stop the stale form from existing
on the client

also using Response.Expires works but i feel it
is bad practice to force a roundtrip when somebody
is pressing back, and may not be interested in that
page but one further back

the way i stop stale forms from being an issue
on the server is to give each form state context
an id and sequence number which must match
the next post

you can make this strong by sticking a digest of the url
plus a secret onto the end of the url, ie:

page.asp?id=1&seq=4&hash=847389473987439

or even lock it down further by including the referer url
in the digest

all of this is ok for protecting server from damage
but what about cleaning up all those stale forms
in the browser history?

the ideal would be something like:

form.submitWithReplace();

i am surprised it isn't an option in HTML itself:

<form action="page.asp" method="post" replace="yes">

as once a form has been submitted it rarely has any
value to anybody?

 

[Tim_Mac]

hi john,
i know what you mean, it is a bit of a pain to have an invalid browser
history.
especially considering that we are now in the realm of web applications,
rather than collections of informational web pages. however that is the
model we still have to work with and back/forward will be with us for the
foreseeable future, with all of it's side effects in the web application
paradigm.

one way i use to work around this problem, is to call
Response.Redirect(Request.Url.PathAndQuery) at the end of my postback code
(provided the user should stay on the same page, i.e. tyipcal datagrid
scenario). this has the effect of replacing the current page in the browser
history, which i think is what you want.
if you test this out on a web form that has a button. at the end of the
button_click code, redirect the user to the same page, and you'll see that
there is no option to go back or forward in the browser history. it has the
added advantage of not allowing form re-posts. and the user can refresh the
page without getting hung up on "repost the data?".

it doesn't work for redirecting to other pages though. i think .net 2.0 and
vista have some improvements for the web application model. the "navigator
app" supports forward and backward browsing, but there is another type
(forget the name) that doesn't allow back/forward functionality. you can
choose the type at compile time as far as i recall.

this probably won't solve your problem but i thought i would reply anyway.
tim