no history

[Christian Schmidt]

Hello,

ist it possible to mark a HTML-page not to be pushed into the browsers
history list (so that you can't go back i.e. via the Browsers Back-Button)?
May be there are some <META>-Tags for doing that?? Or some
Javascript-Statements??

The background is that I implemented a little Perl script for editing a
(very ) simple database. And I want to prevent that the user goes back
and recalls pages with earlier entries he made...

Is that possible via HTML ?

Thanks in advance
Chriastian

 

[Chris]

I'm not an expert but I think you could control the page with cookies and
have the cookie expire once the user had left the page.

Chris.

 

[Kris]

ist it possible to mark a HTML-page not to be pushed into the browsers
history list.

No. Stay away from pondering how to affect the user's browser functions.
It is in almost every case wrong.

The background is that I implemented a little Perl script for editing a
(very ) simple database. And I want to prevent that the user goes back
and recalls pages with earlier entries he made...

That is what the History and the Back button are for.

 

[Andrew Urquhart]

Hello,

Hi Christian.

ist it possible to mark a HTML-page not to be pushed into the
browsers history list (so that you can't go back i.e. via the
Browsers Back-Button)? May be there are some <META>-
Tags for doing that?? Or some Javascript-Statements??

The background is that I implemented a little Perl script for
editing a (very ) simple database. And I want to prevent that
the user goes back and recalls pages with earlier entries he
made...

Is that possible via HTML ?

HTML is means to mark up information, it doesn't tell user-agents how to
implement user-agent features.

1. Don't try and break the back button (such as via meta redirects:
http://www.w3.org/QA/Tips/reback)
2. Javascript won't help much either (http://jibbering.com/faq/#FAQ4_2)

You should look to adding this support more robustly to your
application.

1. Use a more restrictive caching regime (do this with HTTP headers, not
meta tags) so that going back in the user-agent history (hopefully)
makes fresh requests to the server and doesn't pull files out of the
cache, this isn't foolproof though.
2. Clearly indicate to the user that they should not go back and
indicate the consequences of doing so.
3. When a user updates the database add a timestamp indicating when the
database was last updated, and in each instance of an update form place
a hidden field with the same timestamp value in it. When the client
submits a form compare the timestamp in the submitted form data to the
timestamp in the database. If the form timestamp is the same as the
database timestamp it is safe to update the database as no other updates
have occurred between the time the client fetched the initial form
webpage and the time it was submitted. If the form timestamp is younger
than the database timestamp then the data has been updated in the
intervening period (either by someone else, or by the same client
submitting a form and the going back in their history to an older
version of the form). In this case send the submitted data back to the
client, repopulate the form as it was before submission and write out
the newer data as 'plain text' with an appropriate explanation so he or
she can see both what was submitted and what the database was updated
with. The user can then decide whether to quit now and keep the data as
it stands in the database, submit their original data again or edit
their submission to account for the changes. There are other ways to
implement this, but you get the idea. This third option provides a much
more robust mechanism.

 

[Christian Schmidt]

3. When a user updates the database add a timestamp indicating when the
database was last updated, and in each instance of an update form place
a hidden field with the same timestamp value in it. When the client
submits a form compare the timestamp in the submitted form data to the
timestamp in the database. If the form timestamp is the same as the
database timestamp it is safe to update the database as no other updates
have occurred between the time the client fetched the initial form
webpage and the time it was submitted. If the form timestamp is younger
than the database timestamp then the data has been updated in the
intervening period (either by someone else, or by the same client
submitting a form and the going back in their history to an older
version of the form). In this case send the submitted data back to the
client, repopulate the form as it was before submission and write out
the newer data as 'plain text' with an appropriate explanation so he or
she can see both what was submitted and what the database was updated
with. The user can then decide whether to quit now and keep the data as
it stands in the database, submit their original data again or edit
their submission to account for the changes. There are other ways to
implement this, but you get the idea. This third option provides a much
more robust mechanism.

Yep, I was afraid to have to do it as you describe above. Thanks Andrew.

Regards
Christian