OK, I'm getting ready to pull my hair out! is there a way to "unset" or otherwise DESTROY the contents of a $_POST variable in my script? This is for a login/logout script. If the user chooses to logout, I do not want them to be able to use Browser back button & REFRESH to have access again to protected data. I am using Sessions, but the initial data comes via a $_POST variable which my script needs to destroy in the event that a user is logging out! Thanks for your assistance! P.S. I want to avoid using multiple script files to process a login/logout request; there's got to be a way to do this within ONE script file! Thanks again!
Mr. D, thanks for your reply, but unset() does not seem to work in the event of a REFRESH on the browser...why I'll never know? anybody??? I always thought a refresh request made a totally new request to the server for the page, which in turn would force the script to process itself again, but the $_POST variables seem to retain the previous values despite my best efforts! Again, I don't mind them being there UNLESS the user has decided to LOGOUT, in which case they need to be destroyed...anybody know how?
POST data will only ever be available for the page it's been submitted to. If you refresh a browser on a page that you previously had made a POST request for, it will usually resend the post data - which may give the appearance of retaining the data. If you log out and go back to the first page after login (i.e. the page you sent the post data to or to put it another way, the action attribute of the login form) and refresh, you are effectively logging back in. You could create an additional page that processes the login and does a redirect back to your desired page. That way, you're not viewing the page from a POST request and as such the post data previously sent will not be resent if the page is reloaded.
so essentially, I'm forced to use a "go-between" script page when using POST variables to avoid this issue? You are saying that the POST variable data is internally attached to the form action that the data was posted to and I cannot undo that with any type of "unset" operation, correct? Just want to make sure I"m understanding you! Doesn't this present a security issue? If I use a "go-between" script page, let's call it "login", and that validates a user's login criteria and directs my user to the "successful login" page, can't a user type the URL to my login page directly in their browser and achieve the same effect that I'm trying to avoid? This seems like a cluster $#!@.....
I'm saying POST data is sent by the client when you fill in a form that uses the POST method. For the script it was sent to, that data is available (in PHP) through the $_POST array. Normally if you go back to a page you previously accessed from sending a POST request and refresh, you want to resend the data to get the same page as before. In Firefox you get an alert asking you to confirm you do want to resend the data. You can do whatever you want to the POST data and those changes will apply for the duration of that scripts execution. But if the user then goes back and refreshes the page, the data is resent and the script is run again. If the script is a login script, they will get logged in again. You could prevent it using sessions to ensure that once the form has been submitted, however many times its submitted again it won't do anything but the easier solution is to separate your login processing from your content displaying. Even this forum shows you a "redirecting" screen on login. It's not a security issue because you are (or you should) authenticate the session on each page load. Your login script processes your POST data and gives you a session. Your other pages then check you have a valid session or redirect to the login page.