The JavaScript code to implement this feature is as follows:
As shown:
| The code is as follows |
Copy Code |
<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. Use this
The instance of the method is as follows:
| The code is as follows |
Copy Code |
<a href= "pagename.htm" onclick= "Javascript:location.replace" (THIS.HREF); Event.returnvalue=false; ">
|
No link back to this page </A>
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.
When the keyboard knocks down the back key (Backspace)
1, prevent the browser automatically back
2, but does not affect the password, single line text, multiline text input box, such as the fallback operation
| The code is as follows |
Copy Code |
| <script type= "Text/javascript" >
Handle keyboard events No back key (Backspace) password or single line, multiline text box except function Banbackspace (e) { var ev = e | | window.event;//Get Event Object var obj = Ev.target | | ev.srcelement;//Get Event Source
var t = Obj.type | | Obj.getattribute (' type ');//Get Event Source Type
Get the event type as a criterion var vreadonly = Obj.getattribute (' readonly '); var venabled = Obj.getattribute (' enabled '); Handling Null value conditions Vreadonly = (vreadonly = null)? False:vreadonly; venabled = (venabled = null)? true:venabled;
When you hit the BACKSPACE key, the event source type is a password or a single line, multi-line text, And the ReadOnly property is True or the Enabled property is False, the BACKSPACE key is invalidated var flag1= (Ev.keycode = = 8 && (t== "Password" | | t== "TEXT" | | t== "TEXTAREA") && (Vreadonly==true | | venabled!=true)) True:false; When the BACKSPACE key is hit, the event source type is not a password or a single line or multi-line text, the BACKSPACE key is invalidated var flag2= (Ev.keycode = = 8 && t!= "password" && t!= "text" && t!= "textarea") ? true:false;
Judge if (Flag2) { return false; } if (FLAG1) { return false; } }
No back key for Firefox, Opera Document.onkeypress=banbackspace; No back key acts on IE, Chrome Document.onkeydown=banbackspace;
</script> |
All of the above is a response to the back button, and the client browser needs to open the JavaScript code and try to solve the problem from another perspective:
4, Prohibit caching
<%
| The code is as follows |
Copy Code |
Response.setheader ("Cache-control", "No-cache"); Response.setheader ("Cache-control", "No-store"); Response.setdateheader ("Expires", 0); Response.setheader ("Pragma", "No-cache"); |
%>
This method uses server-side scripting to force browsers to reconnect to the server download page, instead of reading from the cache, combining the <logic> tags in the Struts JSP page to achieve redirection.
All of the above methods have certain limitations