Cisco Certified Network Associate Exam,640-802 CCNA All Answers ~100/100. Daily update
Popular posts from this blog
I am using the slimScroll plugin for jQuery by Piotr Rochala Which is a great plugin for nice scrollbars on most browsers but I am stuck because I am using it for a chat box and whenever the user appends new text to the boxit does scroll using the .scrollTop() method however the plugin's scrollbar doesnt scroll with it and when the user wants to look though the chat history it will start scrolling from near the top. I have made a quick demo of my situation http://jsfiddle.net/DY9CT/2/ Does anyone know how to solve this problem?
The page I am working on has a javascript function executed to print parts of the page. For some reason, printing in Safari, causes the window to somehow update. I say somehow, because it does not really refresh as in reload the page, but rather it starts the "rendering" of the page from start, i.e. scroll to top, flash animations start from 0, and so forth. The effect is reproduced by this fiddle: http://jsfiddle.net/fYmnB/ Clicking the print button and finishing or cancelling a print in Safari causes the screen to "go white" for a sec, which in my real website manifests itself as something "like" a reload. While running print button with, let's say, Firefox, just opens and closes the print dialogue without affecting the fiddle page in any way. Is there something with my way of calling the browsers print method that causes this, or how can it be explained - and preferably, avoided? P.S.: On my real site the same occurs with Chrome. In the ex
- Get link
- Other Apps
This question is very similar to this one...
ReplyDeleteYou need to force the cache to expire for this to work. Place the following code on your page code behind.
Page.Response.Cache.SetCacheability(HttpCacheability.NoCache)
Do not disable expected browser behaviour. Make your pages handle the possibility of users going back a page or two; don't try to cripple their software.
ReplyDeleteOthers have taken the approach to say "don't do this" but that doesn't really answer the poster's question. Let's just assume that everyone knows this is a bad idea, but we are curious about how it's done anyway...
ReplyDeleteYou cannot disable the back button on a user's browser, but you can make it so that your application breaks (displays an error message, requiring the user to start over) if the user goes back.
One approach I have seen for doing this is to pass a token on every URL within the application, and within every form. The token is regenerated on every page, and once the user loads a new page any tokens from previous pages are invalidated.
When the user loads a page, the page will only show if the correct token (which was given to all links/forms on the previous page) was passed to it.
The online banking application my bank provides is like this. If you use the back button at all, no more links will work and no more page reloads can be made - instead you see a notice telling you that you cannot go back, and you have to start over.
I came up with a little hack that disables the back button using JavaScript. I checked it on chrome 10, firefox 3.6 and IE9:
ReplyDelete<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<title>Untitled Page</title>
<script type = "text/javascript" >
function changeHashOnLoad() {
window.location.href += "#";
setTimeout("changeHashAgain()", "50");
}
function changeHashAgain() {
window.location.href += "1";
}
var storedHash = window.location.hash;
window.setInterval(function () {
if (window.location.hash != storedHash) {
window.location.hash = storedHash;
}
}, 50);
</script>
</head>
<body onload="changeHashOnLoad(); ">
Try to hit the back button!
</body>
</html>
Condemning the question without knowing the context is a bit harsh. I, for instance, would love to know the proper way to do this: currently I'm running an online psychology experiment, and sometimes participants press the back button (backspace or 'delete' when on a mac) instead of the enter key, by accident. This can potentially mess up the experiment and thus ruin the data (which thankfully hasn't happened yet). This is obviously a case where the input needs to be confined.
ReplyDeleteOfcourse I do agree that in the rule this is a very bad idea... but that has been made clear abundantly already.
If you rely on client-side technology, it can be circumvented. Javascript may be disabled, for example. Or user might execute a JS script to work around your restrictions.
ReplyDeleteMy guess is you can only do this by server-side tracking of the user session, and redirecting (as in Server.Transfer, not Response.Redirect) the user/browser to the required page.
You should be using posts with proper expires and caching headers.
ReplyDeleteInstead of trying to disable the browser back button it's better to support it.
ReplyDelete.NET 3.5 can very well handle the browser back (and forward) buttons. Search with Google: "Scriptmanager EnableHistory".
You can control which user actions will add an entry to the browser's history (ScriptManager -> AddHistoryPoint) and your ASP.NET application receives an event whenever the user clicks the browser Back/Forward buttons.
This will work for all known browsers
<body onLoad="if(history.length>0)history.go(+1)">
ReplyDeleteThere have been a few different implementations. There is a flash solution and some iframe/frame solutions for IE. Check out this
ReplyDeletehttp://www.contentwithstyle.co.uk/content/fixing-the-back-button-and-enabling-bookmarking-for-ajax-apps
BTW: There are plenty of valid reasons to disable (or at least prevent 1 step) a back button -- look at gmail as an example which implements the hash solution discussed in the above article.
Google "how ajax broke the back button" and you'll find plenty of articles on user testing and the validity of disabling the back button.
i was searching for the same question and found following code on a site. thought to share it here.
ReplyDeletefunction noBack(){window.history.forward()}
noBack();
window.onload=noBack;
window.onpageshow=function(evt){if(evt.persisted)noBack()}
window.onunload=function(){void(0)}
however as noted by above users, this is never a good practice and should be avoided for all reasons.
While i'm looking for the answer myself,
ReplyDelete"Best Practice" is.... outdated... Just like browsers are.(Really browsers are ugly fossils)
The best/safest solution would be for browsers to implement a method/request where the user can grant the page the ability to control the interface.
Why? Because for my current project i'm building a 100% JavaScript built and controlled interface.. And back button's have no place in my project since there is no page change. (Ie bloody fast and no page-flashes because of a refresh.. Just like a real application!)
I know why the ability to "highjack" the interface isn't there, and i understand it. But atleast we should have the ability to request it from the browser! Now that would truly be "best practice" without the highjack dangers.
But browsers being browsers.. I don't expect anything exiting to happen in this regard.