Bugged by a session problem

[drayarms]

I thought I had somewhat of a mastery of sessions, until I encountered this problem.  Basically, I'm trying to built a session expired code which is a little bit deviated from your everyday session expired codes.  I want the user of a website to be logged out automatically after the session expires, and redirected to the login page.  But I also need that, if any other user tried to access that same website without having previously been logged on, he should be redirected not to the login page but the signup page.  So basically, the same page (index.php) should redirect the user to login.php if he was logged in and his session expired after 1 minute, or signup.php if he wasn't logged in and tried to access home.php.

 

So what I tried to do to accomplish this was

 

- Declare two session variables $_SESSION['id'] = "some value from database" and  $_SESSION['logged_in'] = TRUE everytime the user succesfully logs in.

 

-At the top of index.php, right after session_start(), check to see if 1 minute has elapsed since last activity and if so, unset $_SESSION['logged_in'] without destroying the session.  So presumably, all other session variables including $_SESSION['id'] and the session itself remain intact.

 

-Right below that, check if $_SESSION['id'] is set.  If not(meaning the session is not active and hence no user was logged in), redirect to signup.php.  If it is set, then check if $_SESSION['logged_in'] is set and if not, redirect to login.php

 

Now to the code itself

 

 

<?php


//address error handling

ini_set ('display_errors', 1);
error_reporting (E_ALL & ~E_NOTICE);



//Check if max allowable time has elapsed

if (isset($_SESSION['LAST_ACTIVITY']) && (time() - $_SESSION['LAST_ACTIVITY'] > 60)) {

    // last request was more than 1 minute ago

    unset($_SESSION['logged_in']);     // unset logged_in session variable for the runtime


}

$_SESSION['LAST_ACTIVITY'] = time(); // update last activity time stamp



        //Get the current page url to pass on to the session expired page.
$url=urlencode("http://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI']);


//Check whether the session variable id is present or not

if(!isset($_SESSION['id']) || (trim($_SESSION['id']) == '')) {

	 session_destroy();

	 header("location: signup.php");

	exit();

}else{//If session id is set meaning the session is alive and hasn't been destroyed


	if(!isset($_SESSION['logged_in'])){//If this variable is not set, then session must have expired because this is the variable we unset upon sesssion expire. The session is still alive though and we must destroy it

	//Redirect to login.php and pass on the page url

	$msg = "Your Session Expired Due to Inactivity. Login Below";

	session_destroy();


	header("location: login.php?url=$url&msg=$msg");


	}//End of if logged in is not set


}//End of if session id is set




?>

 

 

Well the code works just as i want it to, except for this scenario.  If I login with some user's credentials, and open a new page, by typing in url.com in a new window, this new page doesn't redirect to url.com/signup.php but stays on url.com/index.php and all the session variables are available on this new page just like on the old page that was accessed by actually loging in.  Well that's expected.  The problem is, when the session expires on this page, it gets redirected to url.com/signup.php and not url.com/login.php as expected(note that with the old page that was accessed by actually login in, we do get redirected to url.com/login.php)  Now this bothers me because the website is supposed to be redirected to signup.php only if the user started a fresh session without having been logged in as the logic from the code above shows.  So, the $_SESSION['id'] variable actually exists(and I actually tested it by echoing it)but yet, the code behaves as if it doesn't with every new page.  What could possibly be going on here? I have tried using session_regenerate_id(), but that just keeps the session going without ever expiring.  I tried to use the actual session_id()itself in the place of $_SESSION['id'] but in that scenario, the page always gets redirected to url.com/login.php regardless of whether a user was previously logged in or not.

 

 

PS:  I dont think this has anything to do with the problem but worth noting that the url of a page opened after a user logs in is url.com/index.php but that of a page opened after a user is already logged in is simply url.com

[seanlim]

I'm not exactly sure, but even as a best-practice, it isn't advisable to use == for string comparisons as it might return some unexpected results. http://www.php.net/manual/en/language.operators.comparison.php

 

I would suggest using strcmp for your condition instead of trim($_SESSION['id'])==''

[Muddy_Funster]

Best thing you could do is store the logged_in as a cookie, not a session variable.

 

when you say all the $_SESSION variables are there on the index page of the new window, have you actualy done a var_dump($_SESSION) on this page to verify that every variable is set as you would expect it?

 

I'm not exactly sure, but even as a best-practice, it isn't advisable to use == for string comparisons as it might return some unexpected results. http://www.php.net/manual/en/language.operators.comparison.php

 

I would suggest using strcmp for your condition instead of trim($_SESSION['id'])==''

I have to confess, in all the lines of code I've done, i've never once had a problem caused by using == in string comparison (a couple of issues with === but none with ==).

[drayarms]

@ muddy, well, i don't want to use cookies for security concerns, and also in case the user has cookies disabled.  and as for making sure the variables actually exist, well i did echo them on the home.php page and they get printed when the user is logged in. so i can be positive that the variables exist when the user is logged in.

[Muddy_Funster]

what security concerns? all your cookie needs to include is a hash value that you can check.  As for not having cookies enabled, I don't think there is a browser out now that doesn't alow for site specific exeptions to cookies - just put up a message saying cookies for your site must be enabled, like FaceBook does (and an actual security bonus of cookies is that the don't populate through proxies).

 

If you're going down the paranoid route, just keep everything in the database.  Create a new table that has an encrypted key and timestamp with ON UPDATE CURRENT_TIMESTAMP(), only carry the key through the session, refreshing it on every page and with every action and check active times against the timestamp in the table.