The Back button of the browser allows us to easily return to the pages we visited before, and it is certainly useful. But sometimes we have to turn this feature off to
Prevents users from disrupting scheduled page access order. This article describes various options for disabling browser fallback buttons available on the network, analyzing their pros and cons and their suitability
Use the occasion.
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 previous bangs
The page you've been browsing? "At the ASP forum, this question is one of the most frequently asked questions." Unfortunately, the answer is very simple: We cannot disable browser fallback
Button.
At first I was amazed that someone wanted to disable the browser's Back button. Later on, seeing that there were so many people who wanted to disable this back press
button, I also feel relieved (want to disable only the back button, not including the browser's Forward button). Since the user submits the form by default, it can
The Back button returns the form page instead of using 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
Would like 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
Frequent access to ASP programming Web sites, some of the content described in this article you may have seen. The task of this article is to introduce all kinds of possible methods to everyone, and then find
Out 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 regain access to the server download page, rather than reading the page from the cache. When using this method, the programmer's master
The 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. Because of the bangs
The browser no longer caches this page, and when the user clicks the Back button, the viewer downloads the page again, and the program can check that session variable to see if
Users should be allowed to open this 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
&single; The user has visited the current page and is now returning to visit again.
&single; Clears the session variable and redirects the user to the login page.
Session ("firsttimetopage") = ""
Response.Redirect "/bar.asp"
Response.End
End If
&single; If the program is running here, it shows that the user can view the current page
&single; 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 not the first time (that is, session
("Firsttimetopage") contains a value, then we clear the value of the session variable and redirect the user to a start page. This way, when the form
At the time of submission (when Sompepage.asp is opened), we must give firsttimetopage a value. That is, in the somepage.asp we need to add the following
The code:
Session ("firsttimetopage") = "NO"
In this way, the user who has already opened the somepage.asp, if clicked the Back button, the browser will request the server to download the page again, the server checks to session
("Firsttimetopage") contains a value, then clears the session ("Firsttimetopage") and redirects the user to another page. Of course, all
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 session 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:
"Pragma:no-cache" Prevents browsers from caching pages only when using secure connections. For a page that is not secured, "Pragma:no-cache"
is considered to be the same as "Expires:-1", when the browser still caches the page, but marks the page as immediately expired.
In IE 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 you are 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 very
worthy of reference. However, I noticed that if you use this method, although the user clicks the Back button, he will not see the page before the data, but just click
Hit two times, this is not what 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 open a window with client JavaScript that does not have a toolbar, which makes it difficult for users to return to the previous page, but
It's 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 think
This method is not worthy of serious consideration, because we cannot let the user open a new window every 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 the effect of clicking the Forward button, which also offsets the action that the user clicks on the Back button. The JavaScript code to implement this feature is as follows
As shown:
<script language= "JavaScript" >
<!--
Javascript:window.history.forward (1);
-->
</script>
Similarly, this method is effective, but far from the "best method". And then I saw someone suggest using location.replace from a
The page is transferred to another page. 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
The fallback 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. Use this
The instance of the method is as follows:
<a href= "pagename.htm" onclick= "Javascript:location.replace" (THIS.HREF);
Event.returnvalue=false; ">
No link back to 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 each time a user moves from one page to another,
We all have to clear location.history with client code. Also note that this method clears the last access history, not all
's access record.
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 the methods introduced here
Can prevent users from returning to the previous page to varying degrees and in different ways, but they all have their own limitations. Because there is no back button that can be completely disabled
, so the best solution would be to mix client script and server-side scripting.
