Full review of "Disable browser fallback" _css/html

The browser's Back button makes it easy to return to previously visited pages, which is undoubtedly useful. But sometimes we have to turn this feature off to
Prevents users from disrupting scheduled page access orders. This article describes the various disabling browser Back button scenarios that can be found on the network, analyzing their pros and cons and
Use the occasion.
I. Overview
Many people once asked, "How can I disable the browser's Back button?" "or" How to prevent users from clicking the Back button to return to the previous
The pages you've viewed? "In the ASP forum, this question is also one of the most asked questions. Unfortunately, the answer is simple: We can't disable the browser's fallback
Button.
At first I was amazed that someone wanted to disable the browser's Back button. Later, I saw so many people want to disable this back press
button, I will also be relieved (want to disable only the back button, not including the browser's Forward button). Because by default, a user submits a form that can pass
Over Back button to return to the form page (instead of using the "edit" button!) ), and then edit and submit the table again to insert a new record into the one-way database. This is what we don't
wish to see.
So I decided to find a way to avoid this situation. I have visited a number of websites, referencing the various implementations described on these sites. If you
Visit the ASP Programming website frequently, some of the content that this article describes you may have already seen. The task of this article is to introduce all possible methods to everyone, and then find
The best way out!
Second, prohibit caching
In many of the scenarios I've found, one of the suggestions is to disallow page caching. Specifically, use the server-side script 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 re-access the server download page instead of reading the page from the cache. When using this method, the master of the programmer
The task is to create a session-level variable that determines whether the user can still view the page that is not suitable for access through the back button. As the Bangs
The browser will not cache this page, and when the user clicks the Back button, the viewer downloads the page again, and the program can check the session variable to see if
The user 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 already visited the current page and is now back to access 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 runs here, the user is able to view the current page
&single; The following starts creating the form
%>

We use the session variable Firsttimetopage to check if the user is accessing the current page for the first time. If it is not the first time (i.e. session
("Firsttimetopage"), we clear the value of the session variable and redirect the user to a start page. This way, when the form
On commit (at this point sompepage.asp is opened), we must give firsttimetopage a value. That is, in somepage.asp we need to add the following
The code:
Session ("firsttimetopage") = "NO"
In this way, users who have already opened the somepage.asp will be asked to restart the server download page if they click the Back button, the server checks to the session
("Firsttimetopage") contains a value, so it clears the session ("Firsttimetopage") and redirects the user to another page. Of course, all
All this requires the user to enable the cookie, otherwise the session variable will be invalid. (For more instructions on this issue, see for session variables
To work, must the Web visitor has cookies enabled?)
In addition, we can use client-side code to make the browser no longer cache Web pages:






If you use the method above to force the browser to no longer cache Web pages, you must be aware of the following points:
Only "Pragma:no-cache" prevents the browser from caching pages when using a secure connection. For pages that are not secured, the "Pragma:no-cache"
is considered to be the same as "Expires: 1", at which point the browser still caches the page, but marks the page as expiring immediately.
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. But
If it is in an intranet environment, the administrator can control which browser the user uses, and I think someone will use this method.
Third, other methods
The next way we're going to discuss this is to use the back button itself as the center, not the browser cache. Here's an article rewiring the back button is very
worthy of reference. But I've noticed that if you use this method, although the user clicks the Back button, he won't see the page where the data was previously entered, but as long as the point
Two hits, that's not what we want, because in many cases, stubborn users can always find ways to circumvent precautions.
Another way to disable the back button is to use client-side JavaScript to open a window with no toolbars, which makes it difficult for users to return to the previous page, but
Not impossible. A more secure but rather annoying approach is to open a new window when the form is submitted, while closing the window where the form is located. But I feel
This method is not worthy of serious consideration, because we can not allow users to open a new window every submission of a form.
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 create the effect of clicking the Forward button, which also offsets the action of the user clicking the Back button. The JavaScript code to implement this functionality is as follows
As shown:

Similarly, although this method is effective, it is far from the "best approach". Then I saw someone suggest using location.replace from a
Page to go to another page. The principle of 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 then
The rewind button will never become available. I think this may be the way many people seek, but it's still not the best way to do it in any situation. Use this
The example of a method is as follows:
Event.returnvalue=false; ">
No links back to this page
Try this link below:
No links back to this page!
The downside to this approach is that simply using Response.Redirect will no longer work because every time a user goes from one page to another,
We all have to clear the location.history with the client code. It is also important to note that this method clears the last access history, not all
Access Records.
Click on the link above and you will open a simple HTML page. Then click the Back button, you can see that this page is not open, but this page
Before the page! (Of course, you must have client-side 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 described here
are able to prevent users from returning to the previous page in varying degrees and in different ways, but they all have their own limitations. Can disable the back button completely because there is no
approach, so the best scenario should be: Mix client script and server side script.

