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.

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.

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

If you are asking people to log in then presumably each page requiring login enforces it, so security is not an issue.

If someone logs out, hits the back button, then tries to do something requiring login, then just redirect to the login page (w/ a message saying something like "You must login to ..."). This shouldn't be confusing since they actively logged themself out.

sorry How u can detect they are pressing the back button. for me i have use the verify sessionid develop by my self to check the valid id, so it will redirect them to the login page again, but only happen is the page has refreshes from the cgi script.

You don't have to! If you've set it all up correctly, you will have somehow marked the user (using a cookie, or some server storage keyed by session ID) as logged out. Then, when the user attempts to do something involving login, your program will see that they are logged out, and tell them to log in again.

Do not use IP address to determine anything about a visitor.

-- Randal L. Schwartz, Perl hacker

What my terse associate means is ip addresses may not be particularly meaningful or usable in a medley of cases, such as AOL users (dynamic ip allocation via their proxy), accumulating connections (office buildings going out through a single ip address), and spoofed connections.

It is safer and easier to do without them.

EEjack