Re: Help how to disable the Back Button in the browser

Assuming that you're following up on previous advice given, any method that you can use to disable the back button can effectively be overriden.

Now, since you are using sessionIDs, you should be able to determine the user that is using it; given this, you should be able to track if the user is logged in or not. Thus, when you get to a page that processes a session id, check the logged in status of the user for that; if logged in, proceed as normal, otherwise let the user know they are logged out and they need to log in again to continue. So if the user starts on page A, logouts out to result page B, goes back to A, then clicks on a link that would normally go to page C if they were logged in, present them with page D that tells them they need to log in again.

Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain

Comment on Re: Help how to disable the Back Button in the browser

Replies are listed 'Best First'.
Re: Re: Help how to disable the Back Button in the browser by Anonymous Monk on Jun 25, 2001 at 07:05 UTC
Sorry, coz i have a login page for the user to login and then will go into the main page, in the main page there is a logout button. the session id will be created in the main page and the checking will be in here too. when there press the logout button in the main page, the user will be redirect to the logout page and the sessionid will also be deleted. but although it seem to be like this way, but when i click the back button it still can go back to the main page, although i had include the checking for the valid sessionid. it seem that the back button is capturing the html script(when u use the view source can see the html script) when u click the back button rather than refresh the who page by loading the cgi script. so what should i do since i also included the expiry, no cache in the query header part.	[reply]
Re: Re: Re: Help how to disable the Back Button in the browser by Masem (Monsignor) on Jun 25, 2001 at 15:13 UTC
Unfortunately, even with no-cache and expires headers (have you checked to make sure these are put in correctly and in the right place?) the browser is free to ignore them; most browsers will converse bandwith by bringing up the cached version of the page instead of resending the information. But the solution of checking the sessionID verses the user's ID and their logged-in status (all which you should be maintaining in this case) will work; assuming that any links from the main back (the one you're trying to prevent people from going back to) are through other CGI scripts for your site; what you should do is not necessarily delete the sessionID but tag it as 'completed', and leave it in whatever storage medium you have for some reasonable period of time (on the order of hours). When a user visits a page, you should check the sessionID: if no sessionID exists, ask them to log in; if a sessionID exists and is still open, continue as usual. If a sessionID exists and is marked closed, ask the user again to log in to access that information. Dr. Michael K. Neylon - mneylon-pm@masemware.com \|\| "You've left the lens cap of your mind on again, Pinky" - The Brain	[reply]