Best way to check if a user is logged in?

[popcornplya]

What is the best/most secure way to check if a user is logged in (sessions)

[JasonLewis]

if(!isset($_SESSION['user_session'])){
//not logged in
}

 

???

[popcornplya]

But that's not secure 

[The Little Guy]

Create a session when the user logs in, set it to TRUE

 

In the following code I used logged as my session name.

session_start();
if(!$_SESSION['logged']){
     header("location: /login.php");
     exit;
}
// No else required

[JasonLewis]

But that's not secure 

 

How so?

[PFMaBiSmAd]

The most secure way of checking if a user is logged in/logged out is to store the logged in/logged out status in your user table in a database. When they log out, set the value in the database table to indicate they are logged out. The only way this value can be changed to "logged in" is if they supply the correct username/password.

 

Don't use the existence/absence of a value in a session/a session/a session id or the existence/absence of a a cookie/a value in a cookie to determine the logged in/logged out status. Sessions/cookies should only indirectly identify the visitor. If using sessions, store the session id (which is a unique id) in the user table or if using cookies, generate a unique id and store this in the cookie and in the user table. Then using this unique id from the session id or cookie, find (identify) the user in the user table. Don't store any direct identifying information in a cookie, such as a username or a user id (table row) as these things provide a way of directly impersonating a different user by simply editing the value in the cookie.

[popcornplya]

The most secure way of checking if a user is logged in/logged out is to store the logged in/logged out status in your user table in a database. When they log out, set the value in the database table to indicate they are logged out. The only way this value can be changed to "logged in" is if they supply the correct username/password.

 

Don't use the existence/absence of a value in a session/a session/a session id or the existence/absence of a a cookie/a value in a cookie to determine the logged in/logged out status. Sessions/cookies should only indirectly identify the visitor. If using sessions, store the session id (which is a unique id) in the user table or if using cookies, generate a unique id and store this in the cookie and in the user table. Then using this unique id from the session id or cookie, find (identify) the user in the user table. Don't store any direct identifying information in a cookie, such as a username or a user id (table row) as these things provide a way of directly impersonating a different user by simply editing the value in the cookie.

Nice that really helped! Any more security tips?

[The Little Guy]

what if your host has a problem with lots of requests to the database every time a page loads?

[PFMaBiSmAd]

Most of the major scripts that involve logins/member accounts do what I described. This is so that an administrator has a single point of control where he can disable accounts or change how an account behaves. For example, this forum checks your account status/permissions/user level on each page request. The cookie that is set simply identifies who you are, everything else about what you can do, if you are logged in, if your account has been disabled because you are a spammer is checked each time you request a page.

[The Little Guy]

I check users against my db like this, for instance if I don't want someone to view a page, even if they are logged in.

 

// db query
if($_SESSION['id'] != $row['userID']){
     // This user can not view this content
}else{
     // This user can view this content
}

[corbin]

PFMaBiSmAd, I must say I disagree with you.

 

 

Let's say the session id, A, is stored in a cookie, and you're storing things in a database.

 

 

Let's say the app loads data from the DB based on session ID A.  Isn't that essentially storing the session data in a table?  A session file is accessed based on ID, so in essence, isn't using sessions just skipping a step [the step being a database].

 

 

Or is there something I'm missing?

[The Little Guy]

I agree with corbin.

[PFMaBiSmAd]

For identifying a visitor for the purpose of determining his logged in/logged out status (and any other important access rights), what I wrote provides a single point of access and control.

 

Let us say that I start spamming a site with a post every second and the admin/mod needs to disable my account to stop me. If a cookie or a session variable is the only thing that the code is checking that says I am permitted to post, it would be necessary for the account management code to remove/change that cookie or change/unset the session variable (or destroy the entire session.)

 

Well, you cannot remove/change a cookie unless a page is requested, so each page would need to check the database to find out if it should remove/change the cookie, but if you are doing this, that same piece of information in the database tells you to not let them access the page. Kind of redundant, just use the database directly as I have described.

 

To modify or delete the actual session, the account management code would need to retrieve the session id (assuming it is stored in the database), start the session, and then modify/destroy the session data, but if you are doing this, that same piece of information in the database tells you to not let them access the page. Kind of redundant, just use the database directly as I have described.

 

Also, I can make a copy of a cookie and put it back if it is deleted or I can simply submit the login values to cause the script to set another cookie that says I am logged in or I can start another session and log in again and resume spamming.

 

So, the controlling piece of data that is checked on each page visit to determine if I am logged in (or for any other access rights) must be something external to the cookie/session (if you want the simplest code without a lot of special case conditions in it.)

 

This is kind of the opposite of a single point failure. If you want something to work, you avoid a single point failure mode. However, if there are times you want something to not work, you want a single point of control at the last common link in the chain. A cookie or a session is not the last common link in the chain we are discussing.

[PFMaBiSmAd]

I check users against my db like this, for instance if I don't want someone to view a page, even if they are logged in.

 

// db query

if($_SESSION['id'] != $row['userID']){

    // This user can not view this content

}else{

    // This user can view this content

}

 

LoL, you ARE doing exactly what I have described, how can you agree with someone that is disagreeing with doing it that way.

 

And if anyone else still has a problem, please carefully read what I wrote. I wrote about one possible direct/simplest to code/foolproof way of using an identifying piece of information and determining the logged in/logged out (or other important) status that corresponds to that piece of identifying information.

[The Little Guy]

So then what is wrong with this:

 

session_start();
if(!$_SESSION['logged']){
     header("location: /login.php");
     exit;
}
// No else required

[PFMaBiSmAd]

Nothing is wrong with that, as long as you never need the ability to stop someone who is already logged from abusing your site.

[corbin]

I misunderstood you.

 

 

I wasn't looking at it as a 'linear' ish chain.  I was assuming there would be other ways to stop users (such as banned flags or what ever).  Based on just an isset on a session, yeah that would be quite difficult to stop the user (would have to clear sessions, or go through all of the session files looking for the username).

 

 

 

Edit:  And I was assuming data would be repulled from the DB based on a session ID if needed.  (Something like a ban flag), and not stored in a session, so essentially I was doing it your way and misunderstood what you were saying ;p.  lol

 

 

 

 

 

*Sticks foot in mouth*

[The Little Guy]

session_start();
if(!$_SESSION['logged']){
     header("Location: /login.php");
     exit;
}
$sql = mysql_query(sprintf("SELECT * FROM dbTable WHERE id = '%s'",mysql_real_escape_string($_SESSION['id'])));
if(mysql_num_rows($sql) > 0){
     $row = mysql_fetch_array($sql);
     if($row['banType'] == 'spam'){
          echo 'You are banned for spamming this area!';
     }elseif($row['banType'] == 'words'){
          echo 'You are banned for your use of words in this area!';
     }elseif($row['banType'] == 'overAccess'){
          echo 'You are banned for accessing this area too many times too fast!';
     }else{
          // This user has access
     }
}

 

If you say this is what your talking about, then I am confused about what your are trying to prove.

[PFMaBiSmAd]

Checking value(s) in a database to determine what a visitor is allowed to do (logged in/logged out, banned, access rights...) and just using a cookie/session to identify the visitor (pointing to his information in the database) is what I am suggesting.

 

From an administration standpoint and from the simplest coding standpoint, you can find and change the values for any visitor in a database table a lot easier than trying to modify/delete cookies or sessions for that visitor.

[blueman378]

i think both you guys are right,

 

i mean your basically saying the same thing.

 

you use a cookie/session to identify if a user is logged in, but thats it, you query the database for the rest.

 

you would use the session/cookie to tell it what information to look for in the database, or wiether to look at all, (why try to check what permissions they have if not logged in?)

 

but your site should not run on the assumption that the data stored in a session is the current data, eg for the ban, say you have a ban flag in your database if you only check/set the sessions on login they would not be banned till they relogin.

 

 

am i on the right track?