Jump to content

Recommended Posts

And the same goes for if you save their login as a Cookie.  All they have to do is navigate back to one of your favorites and now they are logged in.  If you leave your PC unlocked when you leave, then maybe you need to rethink your own security practices.

To the members asking why the back-button (or browsing to a page) and getting logged back in is a problem, suppose you log out and leave your desk. Anyone can walk up to your computer and hit the back-button or view the address history and select a page you were just on. Do you want them to become logged in?

 

I'm asking why its a problem because it shouldn't be.. I realize that you don't want someone to be logged in after you logout but my question was this..

 

The process of his script does this

 

Sends ussers to logout page.. then immediately after logout they are redirected to the index.. So naturally FROM THE INDEX PAGE if the users were to hit the back button it would only backup to the logout script which would?

 

anyone? yes re log them out or simply result in error thus where is the problem?

The process of his script does this

 

Sends ussers to logout page.. then immediately after logout they are redirected to the index.. So naturally FROM THE INDEX PAGE if the users were to hit the back button it would only backup to the logout script which would?

 

anyone? yes re log them out or simply result in error thus where is the problem?

 

Okay then well either a) it's not really doing that, because he clearly says that when he clicks the back button, it goes to the screen with the info, or b) perhaps he is multi-clicking the back button.

To the members asking why the back-button (or browsing to a page) and getting logged back in is a problem, suppose you log out and leave your desk. Anyone can walk up to your computer and hit the back-button or view the address history and select a page you were just on. Do you want them to become logged in?

 

Yeah, they CAN see the page the user was on, but if they try to perform an action (i.e. send a PM if it's an inbox), it should give a "you are not logged in error" because the session was unset, so what's the problem?

The problem is if they are at a public computer.  Jane User finishes his business, logs out, walks away.  Next random Joe gets on the computer, presses the back button a few times, and blam, he sees sees Jane's logged in info.

 

The whole concept of logging in/out is not to protect the user from himself. It's to protect the user from other people.  And also to protect the server from people, but that's not really applicable to this scenario.

The problem is if they are at a public computer.  Jane User finishes his business, logs out, walks away.  Next random Joe gets on the computer, presses the back button a few times, and blam, he sees sees Jane's logged in info.

 

The whole concept of logging in/out is not to protect the user from himself. It's to protect the user from other people.  And also to protect the server from people, but that's not really applicable to this scenario.

 

you explained the problem exactly. when the user clicks on the Back button, it goes back to the inbox page, of course if the user tries to do anything at that point, i have validation that will check if the session is valid or not. the problem is i do not want them to see that inbox page thats still stuck in the cache. somehow in FF the inbox page stays in the Cache even after the logout script has done its work (succesfully destroyed session) but in IE i do not have this problem.

 

 

why not just set no caching in a meta tag?

 

header("Expires: Mon, 1 Jan 1990 05:00:00 GMT");
header("Cache-Control: no-store, no-cache, must-revalidate");
header("Cache-Control: post-check=0, pre-check=0, false");
header("Pragma: no-cache");

 

ok this is how i usually do the cache thing? would you guys have any comments on how i can improve it

At this point, posting your code so that the symptoms can be duplicated would be result in the quickest solution.

 

To the best of my knowledge, the caching of form data is separate from the caching of the page. The caching of the page just causes the browser to get the HTML page from the cache or requesting it from the server. Filling in the post data or offering to resubmit it (if that is really what is happening - you have not been real specific in describing what you see) is a separate browser function, that I don't think you can affect using any headers.

ok how bout you do us ALL a favor and simply redirect the user to a page OTHER then the index page once logged out.. there by freeing us all of this retarded problem..

 

LIKE YOUR IMAGE:

 

INDEX>LOGOUT>NOTINDEX  

 

LOGOUT<NOTINDEX

 

problem solved!

 

ps. I hope this didn't sound mean.. I simply noticed everyone busting out all this complicated talk about sessions and cache and blah blah blah... keep it nice short simple and sweet...

I'd say it's just annoying to a user. They also might not know why the window exited. I'd challenge you to find me any top site out there that exits your window after logout... it's just not necessary.

 

 

 

btw, I did the test on my site where I'd logout, and then hit back(in FF) and it redirects me to the login page. I basically have a check_logged_in() function on the top of every single page that requires a user to be logged in, so if the session is destroyed, and you try to go back into it, it will run the function and then redirect you somewhere else.(I'm using the header() function to redirect)

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.