多种屏蔽浏览器的后退按钮的方法
I have had a lot of people ask, "How to I 慸isable?the back button?" or, "How do I prevent a user from
clicking the back button and going back to the previous screen?" In fact, this is one of the most commonly
asked questions on the ASPMessageboard and, sadly, the answer is quite simple: You CANNOT disable the back
button of the browser.
Initially I could not figure why anyone would want or need to do that. Then it struck me as to why so many
people would want to disable the back button. (Not the forward button mind you only the back button.) When
a user submits an application and then goes back "using the back button" to make a change instead of
clicking on "Edit," a new record will be inserted ?we don抰 want that, now do we? Again if the user
finished a page and then went back to that page and continued to make changes and saved them we would not
want that either.
So I decided to figure a way or ways to prevent this scenario. I started doing a bit of research all over
the Net going into various sites so basically this article will have a lot of stuff you might have already
read if you looked on the Net. I am just trying to put it all in one place and find the "best" way of
doing it!
One of the many suggestions I got was to prevent the page from being cached. This can be done with server-
side script:
<%
Response.Buffer = True
Response.ExpiresAbsolute = Now() - 1
Response.Expires = 0
Response.CacheControl = "no-cache"
%>
This method works great! It forces the browser to go to the server to get the page instead of from its
cache. What you will want to do is create a Session-level variable that determines whether or not a user
can still "view" the page that you do not want to let the user navigate back to. Since the page is not
being cached on the browser, the page will be reloaded when the user hits the back button, and you can
check for that session-level variable to see if the user can view this page or not.
For example, we could create a form like so:
<%
Response.Buffer = True
Response.ExpiresAbsolute = Now() - 1
Response.Expires = 0
Response.CacheControl = "no-cache"
If Len(Session("FirstTimeToPage")) > 0 then
'The user has come back to this page after having visited
'it... wipe out the session variable and redirect them back
'to the login page
Session("FirstTimeToPage") = ""
Response.Redirect "/Bar.asp"
Response.End
End If
'If we reach here, the user can view the page, create the form
%>
<form method=post action="SomePage.asp">
<input type=submit>
</form>
Note that we are using a Session variable (FirstTimeToPage) to check to see if this is the users first
visit to this particular page. If it isn't (that is, if Session("FirstTimeToPage") contains any value),
then we clear out the session variable and redirect the user back to some starting page. Now, when the
form is submitted (and SomePage.asp is loaded), we must set the session variable FirstTimeToPage to some
value. So... in SomePage.asp we'd need code like:
Session("FirstTimeToPage") = "NO"
Then, if the user, on SomePage.asp, hits the back button, the browser will requery the Web server, see
that Session("FirstTimeToPage") contains some value, clear Session("FirstTimeToPage"), and redirect the
user to some page. All of this hinges, of course, on the fact that the user has cookies enabled, else
session variables won't work! (For more information on this subject, be sure to check out the FAQ: For
session variables to work, must the Web visitor have cookies enabled?)
You can also use client-side code to force the user's browser to not cache a Web page.
<html>
<head>
<meta http-equiv="Expires" CONTENT="0">
<meta http-equiv="Cache-Control" CONTENT="no-cache">
<meta http-equiv="Pragma" CONTENT="no-cache">
</head>
There are a couple things to keep in mind when using the above method to force a browser to not cache a
Web page:
Pragma: no-cache prevents caching only when used over a secure connection. A Pragma: no-cache META tag is
treated identically to Expires: -1 if used in a non-secure page. The page will be cached but marked as
immediately expired.
Cache-Control META HTTP-EQUIV tags are ignored and have no effect in Internet Explorer versions 4 or 5.
You can use both in your code. I tried this but this was not the solution because it did not work in all
the browsers so I guess if one had an intranet environment where there was some control in place then they
could use this method.
My next area of research focused on the various rewiring the back button suggestions. An article by TJ
Sylvester, Rewiring the Back Button, makes interesting reading but I noticed that when one clicks back it
does not indeed take you to the page you entered the data but if I clicked back twice it does and we would
not want that too. Basically a determined user could always figure out a way to circumvent the
preventative measures.
Another way to "disable the back button" is to use client-side JavaScript code to open a new window that
doesn't have the toolbar. (This makes it harder (not impossible) for the user to go back to the previous
page.) Another, more failsafe approach (although quite annoying) is, when a form is submitted, to open a
new window and close the window that the form existed in. I didn't give this method serious thought
because I would not like my site opening up a new window everytime a user submitted a form.
Next I examined the possibility of adding client-side JavaScript code on the page that we do not want to
let the user return to. Such JavaScript code could be used to have the effect of hitting the forward
button, which would counter any action by a user clicking the back button. The JavaScript code to
accomplish this can be seen below:
<script language="JavaScript">
<!--
javascript:window.history.forward(1);
//-->
</script>
Again this is workable but it is far from the best way. I was then given the suggestion to use
location.replace to navigate form one page to another. What this does is it replaces the current history
entry with the new page so only one page will be maintained in the history and the back button will never
get enabled. This is, I guess, what a lot of people are looking for, but again this would not be the best
answer in all cases.
For one thing you will have to use client side script for this. For an anchor tag this will be easy by
just using:
<A HREF="PageName.htm" onclick="javascript:location.replace(this.href); event.returnValue=false; ">No back
button when you do this.</A>
[Try out the above link!]
The above technique has its disadvantages: simply using Response.Redirect will not work, since, each time
a user jumps from one page to another, you need to clear out the location.history field through client-
side code. Also, keep in mind that this will just remove the last history entry, not all of them. Go ahead
and click the above hyperlink, you will be taken to a simple HTML page. Try clicking the back button and
you will notice you will be taken to the page you were visiting before you came to this page! (Assuming,
of course, you have client-side JavaScript code enabled in your browser.)
After my exhaustive search I found that there is still no way of truly disabling the back button for all
cases. All the methods I discussed in this article will, with varying degrees of success, prevent the user
from viewing the previous page, but they, of course, all have their limitations. The best solution
involves a mixture of both client-side and server-side script; regardless, there is no way to completely
disable the back button... sorry!
clicking the back button and going back to the previous screen?" In fact, this is one of the most commonly
asked questions on the ASPMessageboard and, sadly, the answer is quite simple: You CANNOT disable the back
button of the browser.
Initially I could not figure why anyone would want or need to do that. Then it struck me as to why so many
people would want to disable the back button. (Not the forward button mind you only the back button.) When
a user submits an application and then goes back "using the back button" to make a change instead of
clicking on "Edit," a new record will be inserted ?we don抰 want that, now do we? Again if the user
finished a page and then went back to that page and continued to make changes and saved them we would not
want that either.
So I decided to figure a way or ways to prevent this scenario. I started doing a bit of research all over
the Net going into various sites so basically this article will have a lot of stuff you might have already
read if you looked on the Net. I am just trying to put it all in one place and find the "best" way of
doing it!
One of the many suggestions I got was to prevent the page from being cached. This can be done with server-
side script:
<%
Response.Buffer = True
Response.ExpiresAbsolute = Now() - 1
Response.Expires = 0
Response.CacheControl = "no-cache"
%>
This method works great! It forces the browser to go to the server to get the page instead of from its
cache. What you will want to do is create a Session-level variable that determines whether or not a user
can still "view" the page that you do not want to let the user navigate back to. Since the page is not
being cached on the browser, the page will be reloaded when the user hits the back button, and you can
check for that session-level variable to see if the user can view this page or not.
For example, we could create a form like so:
<%
Response.Buffer = True
Response.ExpiresAbsolute = Now() - 1
Response.Expires = 0
Response.CacheControl = "no-cache"
If Len(Session("FirstTimeToPage")) > 0 then
'The user has come back to this page after having visited
'it... wipe out the session variable and redirect them back
'to the login page
Session("FirstTimeToPage") = ""
Response.Redirect "/Bar.asp"
Response.End
End If
'If we reach here, the user can view the page, create the form
%>
<form method=post action="SomePage.asp">
<input type=submit>
</form>
Note that we are using a Session variable (FirstTimeToPage) to check to see if this is the users first
visit to this particular page. If it isn't (that is, if Session("FirstTimeToPage") contains any value),
then we clear out the session variable and redirect the user back to some starting page. Now, when the
form is submitted (and SomePage.asp is loaded), we must set the session variable FirstTimeToPage to some
value. So... in SomePage.asp we'd need code like:
Session("FirstTimeToPage") = "NO"
Then, if the user, on SomePage.asp, hits the back button, the browser will requery the Web server, see
that Session("FirstTimeToPage") contains some value, clear Session("FirstTimeToPage"), and redirect the
user to some page. All of this hinges, of course, on the fact that the user has cookies enabled, else
session variables won't work! (For more information on this subject, be sure to check out the FAQ: For
session variables to work, must the Web visitor have cookies enabled?)
You can also use client-side code to force the user's browser to not cache a Web page.
<html>
<head>
<meta http-equiv="Expires" CONTENT="0">
<meta http-equiv="Cache-Control" CONTENT="no-cache">
<meta http-equiv="Pragma" CONTENT="no-cache">
</head>
There are a couple things to keep in mind when using the above method to force a browser to not cache a
Web page:
Pragma: no-cache prevents caching only when used over a secure connection. A Pragma: no-cache META tag is
treated identically to Expires: -1 if used in a non-secure page. The page will be cached but marked as
immediately expired.
Cache-Control META HTTP-EQUIV tags are ignored and have no effect in Internet Explorer versions 4 or 5.
You can use both in your code. I tried this but this was not the solution because it did not work in all
the browsers so I guess if one had an intranet environment where there was some control in place then they
could use this method.
My next area of research focused on the various rewiring the back button suggestions. An article by TJ
Sylvester, Rewiring the Back Button, makes interesting reading but I noticed that when one clicks back it
does not indeed take you to the page you entered the data but if I clicked back twice it does and we would
not want that too. Basically a determined user could always figure out a way to circumvent the
preventative measures.
Another way to "disable the back button" is to use client-side JavaScript code to open a new window that
doesn't have the toolbar. (This makes it harder (not impossible) for the user to go back to the previous
page.) Another, more failsafe approach (although quite annoying) is, when a form is submitted, to open a
new window and close the window that the form existed in. I didn't give this method serious thought
because I would not like my site opening up a new window everytime a user submitted a form.
Next I examined the possibility of adding client-side JavaScript code on the page that we do not want to
let the user return to. Such JavaScript code could be used to have the effect of hitting the forward
button, which would counter any action by a user clicking the back button. The JavaScript code to
accomplish this can be seen below:
<script language="JavaScript">
<!--
javascript:window.history.forward(1);
//-->
</script>
Again this is workable but it is far from the best way. I was then given the suggestion to use
location.replace to navigate form one page to another. What this does is it replaces the current history
entry with the new page so only one page will be maintained in the history and the back button will never
get enabled. This is, I guess, what a lot of people are looking for, but again this would not be the best
answer in all cases.
For one thing you will have to use client side script for this. For an anchor tag this will be easy by
just using:
<A HREF="PageName.htm" onclick="javascript:location.replace(this.href); event.returnValue=false; ">No back
button when you do this.</A>
[Try out the above link!]
The above technique has its disadvantages: simply using Response.Redirect will not work, since, each time
a user jumps from one page to another, you need to clear out the location.history field through client-
side code. Also, keep in mind that this will just remove the last history entry, not all of them. Go ahead
and click the above hyperlink, you will be taken to a simple HTML page. Try clicking the back button and
you will notice you will be taken to the page you were visiting before you came to this page! (Assuming,
of course, you have client-side JavaScript code enabled in your browser.)
After my exhaustive search I found that there is still no way of truly disabling the back button for all
cases. All the methods I discussed in this article will, with varying degrees of success, prevent the user
from viewing the previous page, but they, of course, all have their limitations. The best solution
involves a mixture of both client-side and server-side script; regardless, there is no way to completely
disable the back button... sorry!
- 没有相关文章
- 没有评论
