Welcome Guest, Not a member yet? Register   Sign In
Problem with session and "back" in browser
#1

[eluser]rkitkonsult[/eluser]
Hi, I'll hope someone can take their time and help me with this! Smile

My problem:
I have a public page and a member page of a homepage. Login is required to reach the member page. When a login is successful I'll try to start a session and set a parameter in the session. In the member page I check if the session parameter is set and in that case show the page. If the session parameter is not set I redirect them to the public page. When clicking logout button I destroy the session and redirect to public page. Still, after I made a logout, and being in the public page, I can click "back" in the broswer and it will show the private page. How come?

Example of code, just the parts involving the sessions...

//Login controller
class Login extends Controller {

function Login() {
parent::Controller();
...
$this->load->library('session');
}

function index() {
...
if(approved login) {
$row = $query->row();
$user_id_from_authentication = $row->UserID;
$this->session->set_userdata('userid', $user_id_from_authentication);
redirect('/memberpage/');
}
else {
redirect('');
}
}
}


//Logout controller
class Logout extends Controller {

function Logout() {
parent::Controller();
...
$this->load->library('session');
}

function index() {
$this->session->sess_destroy();
redirect('');
}
}

//Member page
class Memberpage extends Controller {

function Memberpage() {
parent::Controller();
...
$this->load->library('session');
}

function index() {

if($this->session->userdata('userid') == TRUE) {
...load view...
}
else {
redirect('');
}
}
}

Shouldnt the session be destroyed when logout and therefore when clicking "back" in browser and Memberpage controller runs again the session->userdata('userid') be unset?

Please help!
#2

[eluser]bigtony[/eluser]
When you click the back button in a browser the browser will try to find a copy of the page in its own cache memory, and if found will not access your webserver (and therefore not see that the login status has changed).

To solve, you need to tell the browser not to cache that particular page. See [url="http://ellislab.com/forums/viewthread/126245/"]http://ellislab.com/forums/viewthread/126245/[/url] for an example of how to do this.
#3

[eluser]GSV Sleeper Service[/eluser]
the CI session library strikes again! find 'native sessions' in the CI wiki and use that, save yourself a lot of hassle.
#4

[eluser]n0xie[/eluser]
[quote author="GSV Sleeper Service" date="1252502800"]the CI session library strikes again! find 'native sessions' in the CI wiki and use that, save yourself a lot of hassle.[/quote]
This problem is inherent to how PHP Sessions work. How do you propose native sessions solves this?
#5

[eluser]GSV Sleeper Service[/eluser]
I don't propose that it 'solves' it, I know, through lots of tests that the default CI session library is a royal pain in the arse - but only with IE for some reason. IE would keep the session for one extra refresh, this problem stopped when I stopped using the CI session library.
I've not looked further into why this should be the case, but I've got a feeling it's something to do with CI sessions not being 'real' sessions, but being cookie based.

clearly this is not 'inherent to how PHP Sessions work' - as I never experienced this issue when using native PHP sessions.
#6

[eluser]rkitkonsult[/eluser]
Thanks for the answers, probably I'll use php native sessions instead then...
#7

[eluser]BrianDHall[/eluser]
Um, if you click 'back' are you sure the page is being reloaded and isn't cached? Have you tried sending a no-cache header on pages where a user is logged in?

If you can reload the page, try setting the value of the main variable you check to an empty string

Code:
$this->session->userdata('logged_in') == '';

and then kill the session. Changes to a variable are instant in all session types, whereas destroying the session is not always instantaneous.

I first learned of this problem with the native PHP session library, years ago. It was no surprise to me how the native session library behaved because of that...well, that's not true. I was surprised because I expected the CI implementation to be better in this regard.

However once you know the inherent limitations with sessions you easily adjust to doing things a certain way so it won't effect your programs anymore.

Try this and make sure you aren't just going back to a cached page before you throw everything out and start using native sessions, as I think you'll find that they are just about as big a pain in the ass as any other implementation is.
#8

[eluser]Unknown[/eluser]
i am have same problem in ci it is bug that after logout you can see private pages on clicking back button on browser
#9

[eluser]osci[/eluser]
From some previous test, (bored to check again, but things shouldn't have changed) using wireshark to see http requests, pushing the back button on your browser does not trigger any request at all.

You shouldn't have a problem with that. Whatever click is done from there will be stopped by your controllers as then you'll get your browser triggering request.
#10

[eluser]leehappy[/eluser]
I like Prada Handbags, prada handbags can reflect a woman's maturity and temperament. It shows a woman's tastes better, and preferences. A good bag can show that you value, so you attract more envy.




Theme © iAndrew 2016 - Forum software by © MyBB