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" οnclick="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!
浏览器的后退按钮使得我们能够方便地返回以前访问过的页面，它无疑非常有用。但有时候我们不得不关闭这个功能，以防止用户打乱预定的页面访问次序。本文介绍网络上可找到的各种禁用浏览器后退按钮方案，分析它们各自的优缺点和适用场合。
一、概述
曾经有许多人问起，“怎样才能‘禁用’浏览器的后退按钮？”，或者“怎样才能防止用户点击后退按钮返回以前浏览过的页面？”我访问了许多网站，参考了这些网站所介绍的各种实现方法。如果你经常访问ASP编程网站，本文所介绍的部分内容你可能已经见到过。本文的任务是把各种可能的方法都介绍给大家，然后找出最好的方法！
二、禁止缓存
在我找到的许多方案中，其中有一种建议禁止页面缓存。具体是使用服务器端脚本，如下所示：
<%
Response.Buffer = True
Response.ExpiresAbsolute = Now() - 1
Response.Expires = 0
Response.CacheControl = "no-cache"
%>
这种方法非常有效！它强制浏览器重新访问服务器下载页面，而不是从缓存读取页面。使用这种方法时，编程者的主要任务是创建一个会话级的变量，通过这个变量确定用户是否仍旧可以查看那个不适合通过后退按钮访问的页面。由于浏览器不再缓存这个页面，当用户点击后退按钮时浏览器将重新下载该页面，此时程序就可以检查那个会话变量，看看是否应该允许用户打开这个页面。
例如，假设我们有如下表单：
<%
Response.Buffer = True
Response.ExpiresAbsolute = Now() - 1
Response.Expires = 0
Response.CacheControl = "no-cache"
If Len(Session("FirstTimeToPage")) > 0 then
"用户已经访问过当前页面，现在是再次返回访问。
"清除会话变量，将用户重定向到登录页面。
Session("FirstTimeToPage") = ""
Response.Redirect "/Bar.asp"
Response.End
End If
"如果程序运行到这里，说明用户能够查看当前页面
"以下开始创建表单
%>
<form method=post action="SomePage.asp">
<input type=submit>
</form>
我们借助会话变量FirstTimeToPage检查用户是否是第一次访问当前页面。如果不是第一次（即Session("FirstTimeToPage")包含某个值），那么我们就清除会话变量的值，然后把用户重新定向到一个开始页面。这样，当表单提交时（此时SompePage.asp被打开），我们必须赋予FirstTimeToPage一个值。即，在SomePage.asp中我们需要加上下面的代码：
Session("FirstTimeToPage") = "NO"
这样，已经打开SomePage.asp的用户如果点击后退按钮，浏览器将重新请求服务器下载页面，服务器检查到Session("FirstTimeToPage")包含了一个值，于是就清除Session("FirstTimeToPage")，并把用户重定向到其他页面。当然，所有这一切都需要用户启用了Cookie，否则会话变量将是无效的。
另外，我们也可以用客户端代码使浏览器不再缓存Web页面：
<html>
<head>
<meta http-equiv="Expires" CONTENT="0">
<meta http-equiv="Cache-Control" CONTENT="no-cache">
<meta http-equiv="Pragma" CONTENT="no-cache">
</head>
如果使用上面的方法强制浏览器不再缓存Web页面，必须注意以下几点：
只有在使用安全连接时“Pragma: no-cache”才防止浏览器缓存页面。对于不受安全保护的页面，“Pragma: no-cache”被视为与“Expires: -1”相同，此时浏览器仍旧缓存页面，但把页面标记为立即过期。
在IE 4或5中，“Cache-Control”META HTTP-EQUIV标记将被忽略，不起作用。
在实际应用中我们可以加上所有这些代码。然而，由于这种方法不能适用于所有的浏览器，所以是不推荐使用的。但如果是在Intranet环境下，管理员可以控制用户使用哪种浏览器，我想还是有人会使用这种方法。
三、其他方法
接下来我们要讨论的方法以后退按钮本身为中心，而不是浏览器缓存。这儿有一篇文章Rewiring the Back Button很值得参考。不过我注意到，如果使用这种方法，虽然用户点击一下后退按钮时他不会看到以前输入数据的页面，但只要点击两次就可以，这可不是我们希望的
效果，因为很多时候，固执的用户总是能够找到绕过预防措施的办法。
另外一种禁用后退按钮的办法是用客户端javascript打开一个没有工具条的窗口，这使得用户很难返回前一页面，但不是不可能。一种更安全但相当恼人的方法是，当表单提交时打开一个新的窗口，与此同时关闭表单所在的窗口。但我觉得这种方法不值得认真考虑，因为我
们总不能让用户每提交一个表单就打开一个新窗口。
那么，在那个我们不想让用户返回的页面是否也可以加入javascript代码呢？在这个页面中加入的javascript代码可用来产生点击前进按钮的效果，这样也就抵消了用户点击后退按钮所产生的动作。用于实现该功能的javascript代码如下所示：
<script language="javascript">
<!--
javascript:window.history.forward(1);
//-->
</script>
同样地，这种方法虽然有效，但距离“最好的方法”还差得很远。后来我又看到有人建议用location.replace从一个页面转到另一个页面。这种方法的原理是，用新页面的URL替换当前的历史纪录，这样浏览历史记录中就只有一个页面，后退按钮永远不会变为可用。我想这可能正是许多人所寻求的方法，但这种方法仍旧不是任何情况下的最好方法。使用这种方法的实例如下所示：
<A HREF="PageName.htm" οnclick="javascript:location.replace(this.href); event.returnvalue=false; ">
禁止后退到本页面的链接
试试下面这个链接：
禁止后退到本页面的链接！
这种方法的缺点在于：简单地运用Response.Redirect将不再有效，这是因为每次用户从一个页面转到另一个页面，我们都必须用客户端代码清除location.history。另外还要注意，这种方法清除的是最后一个访问历史记录，而不是全部的访问记录。
点击上面的链接，你将打开一个简单的HTML页面。再点击后退按钮，你可以看到这时打开的不是本页面，而是本页面之前的页面！（当然，你必须在浏览器中启用了客户端javascript代码。）
经过一番仔细的寻寻觅觅之后，我发现仍旧无法找出真正能够完全禁用浏览器后退按钮的办法。所有这里介绍的方法都能够在不同程度上、以不同的方式禁止用户返回前一页面，但它们都有各自的局限。由于不存在能够完全禁用后退按钮的方法，所以最好的方案应该是：混合运用客户端脚本和服务器端脚本。
扫一扫
1054
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
