Re: Stale Forms
- From: "Tim_Mac" <Tim at mackey dot eye eee>
- Date: Wed, 7 Sep 2005 16:45:25 +0100
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
--------------------------
blog: http://tim.mackey.ie
"John Rivers" <first10@xxxxxxxxxxxxxx> wrote in message
news:1125667069.071808.299680@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> 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?
>
.
- References:
- Stale Forms
- From: John Rivers
- Stale Forms
- Prev by Date: Class Design Question for 3-tier web app
- Next by Date: Re: screen resolution
- Previous by thread: Stale Forms
- Next by thread: important: Trying to coordinate iPlanet with IIS
- Index(es):
Relevant Pages
|
