no history

Discussion in 'HTML' started by Christian Schmidt, Mar 2, 2004.

  1. 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
     
    Christian Schmidt, Mar 2, 2004
    #1
    1. Advertising

  2. Christian Schmidt

    Chris Guest

    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.


    "Christian Schmidt" <> wrote in message
    news:...
    > 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, Mar 2, 2004
    #2
    1. Advertising

  3. Christian Schmidt

    Kris Guest

    In article <>,
    Christian Schmidt <> wrote:

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

    --
    Kris
    <> (nl)
    <http://www.cinnamon.nl/>
     
    Kris, Mar 2, 2004
    #3
  4. "Christian Schmidt" <> wrote in message
    news:...
    > 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.
    --
    Andrew Urquhart
    Reply: www.andrewu.co.uk/about/contact/?subject=Re: alt.html
     
    Andrew Urquhart, Mar 2, 2004
    #4
  5. Andrew Urquhart schrieb:
    >
    > 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
     
    Christian Schmidt, Mar 2, 2004
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. bob

    drop down history

    bob, Oct 25, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    2,888
    Leon Mayne [MVP]
    Oct 26, 2005
  2. szabelin

    asp:buttion , history.back

    szabelin, Jul 7, 2003, in forum: ASP .Net
    Replies:
    4
    Views:
    6,538
    szabelin
    Jul 7, 2003
  3. Sam Stephenson
    Replies:
    1
    Views:
    258
    Andrew Walrond
    Jun 18, 2005
  4. Replies:
    2
    Views:
    455
    nutso fasst
    Oct 17, 2006
  5. Niall
    Replies:
    3
    Views:
    194
    Niall
    Dec 6, 2006
Loading...

Share This Page