"Disable browser Back button" in ASP

BrowserBack button allows us to easily return to a previously visited page, which is certainly useful. But sometimes we have to turn this feature off to prevent users from disrupting the scheduled page access order. This article describes the various options for disabling browser fallback buttons available on the network, analyzing their pros and cons, and how they fit into the situation. I. Overview There was a lot of people asking, "How can I disable the browser's Back button?" ", or" how to prevent users from clicking the Back button to return to a previously browsed page? "InASPOn the forum, this question is one of the most asked questions. Unfortunately, the answer is very simple: We cannot disable the browser's Back button. At first I was amazed that someone wanted to disable the browser's Back button. Later, I see that there are so many people want to disable this back button, I also relieved (want to disable only the back button, not including the browser's Forward button). Because by default, users can return the form page by using the Back button after submitting the form (instead of the Edit button!). And then edit and submit the table again to the one-way database to insert a new record. This is what we don't want to see. So I decided to find a way to avoid this. I've visited a number of web sites to refer to the various implementations described in these sites. If you frequently visit ASP programming sites, you may have seen some of the content described in this article. The task of this article is to introduce all kinds of possible methods to everyone, and then find the best way! Second, prohibit caching Of the many scenarios I've found, one of the suggestions is to prevent page caching. Specifically, use server-side scripting, as follows: <% Response.Buffer = True Response.ExpiresAbsolute = Now ()-1 Response.Expires = 0 Response.CacheControl = "No-cache" %> This method is very effective! It forces the browser to access the server againDownloadpage, rather than reading the page from the cache. When using this approach, the programmer's primary task is to create a session-level variable that determines whether a user can still view a page that is not suitable for access through the back button. Since the browser no longer caches this page, when the user clicks the Back button and the browser downloads the page, the program can check the session variable to see if the user should be allowed to open the page. For example, suppose we have the following form: <% Response.Buffer = True Response.ExpiresAbsolute = Now ()-1 Response.Expires = 0 Response.CacheControl = "No-cache" If Len (Session ("Firsttimetopage")) > 0 Then The user has visited the current page and is now returning to visit again. Clears the session variable and redirects the user to the login page. Session ("firsttimetopage") = "" Response.Redirect "/bar.asp" Response.End End If If the program is running here, it shows that the user can view the current page The following starts creating the form %> <form method=post action= "somepage.asp" <input type=submit> </form> We use session variable Firsttimetopage to check whether the user is accessing the current page for the first time. If it is not the first time (that is, session ("Firsttimetopage") contains a value, then we clear the value of the conversation variable and redirect the user to a start page. So, when the form is submitted (when Sompepage.asp is opened), we must give firsttimetopage a value. That is, in somepage.asp we need to add the following code: Session ("firsttimetopage") = "NO" In this way, if the user who has opened somepage.asp clicks the back button, the browser will request the server to download the page, the server checks to the session ("Firsttimetopage") contains a value, and then clears the session (" Firsttimetopage "), and redirects the user to another page. Of course, all of this requires the user to enable the cookIE, otherwise the session variable will be invalid. (For more information on this issue, see for sessions variables to work, must the Web visitor have cookies enabled?) In addition, we can use client-side code to make browsers no longer cache Web pages: <meta http-equiv= "Expires" content= "0" <meta http-equiv= "Cache-control" content= "No-cache" <meta http-equiv= "Pragma" content= "No-cache" If you use the above method to force browsers to no longer cache Web pages, you must be aware of the following points: Only when usingSafety"Pragma:no-cache" Prevents browsers from caching pages when connected. For unsecured pages, "Pragma:no-cache" is considered the same as "Expires:-1", at which point the browser still caches the page, but marks the page as immediately expired. InIEIn 4 or 5, the "Cache-control" META http-equiv tag is ignored and does not work. In practical applications we can add all of this code. However, since this method does not apply to all browsers, it is not recommended for use. But if it is in an intranet environment, the administrator can control which browser users use, I think someone will use this method. Third, other methods The next thing we're going to talk about is to focus on the back button itself, not the browser cache. Here is an article rewiring the back button is worth reference. I noticed, however, that if you use this method, although the user clicks the Back button, he will not see the previous input data page, but only click two times, this is not the effect we want, because many times, stubborn users can always find a way to bypass the precautionary measures. Another way to disable the back button is to use client JavaScript to open a window without a toolbar, which makes it difficult for users to return to the previous page, but not impossible. A more secure but annoying way to do this is to open a new window when the form is submitted, while closing the window where the form is located. But I don't think this approach is worth thinking about, because we can't let users open a new window every single form is submitted. So is it possible to add JavaScript code to a page that we don't want the user to return? The JavaScript code added to this page can be used to produce a Click forward button, which also offsets the user's click of the Back button. The JavaScript code to implement this feature is as follows: <script language= "JavaScript" > !-- Javascript:window.history.forward (1); --> </script> Similarly, this method is effective, but far from the "best method". Then I saw someone suggest using Location.replace to move from one page to another. The rationale for this approach is to replace the current history with the URL of the new page, so that there is only one page in the browsing history, and the back button will never become available. I think this may be the way many people are looking for, but it's still not the best way to do it in any situation. Examples of using this method are as follows: <a Href= "Pagename.htm" Do not go back to the link on this page </A> Try this link below: No link back to this page! The disadvantage of this approach is that simply using Response.Redirect will no longer work, because every time a user moves from one page to another, we must clear the Location.history with client code. Also note that this method clears the last access history, not all the access records. Click on the link above and you will open a simple HTML page. Then click the Back button, you can see this is not open this page, but this page before the page! (You must, of course, have client JavaScript code enabled in the browser.) ） After a careful search, I found that I still couldn't find a way to really disable the browser back button completely. All of the methods described here can prevent users from returning to the previous page to varying degrees and in different ways, but they all have their own limitations. Since there is no way to completely disable the back button, the best solution would be to mix client and server-side scripts.