Login: Session and Cookies - For more experienced PHP programmers

[bitwise]

Hello, I'm new to PHP, but not to programming by any means. I just wanted to run this by more experienced PHP programmers to see if I'm on the right track.

To authenticate a username/password to login to a website I'm thinking the basic process would go something like this pseudo-code:

start-session
if(check-session = true) {
display secure webpage
}
else
if(check_cookie = true) {
authenticate with database(user/pass) = yes
save-session-information
display secure webpage
}
else {
goto page login.php
}
}

Is this a good process in general? Is it secure?

The reason I'm using a session along with a cookie is because I'm trying to avoid authenticating with the database every single time a secure page is requested. Does this logic make sense?

Thanks!

 

[OsakaWebbie]

Welcome to PHP programming! I too came to it from years of experience with other languages, and have found PHP and web-based programming enjoyable.

I fully understand why you're using a session, but I don't understand why you are using a separate cookie that is not simply the session cookie. My authentication has always been purely sessions. But perhaps you have your reasons. Anyway, a couple things I learned along the way are: (1) rather than going to a separate page for the login form, if you stay in the same URL, you won't have to keep track of where the user wants to go after login; and (2) it's nice to offer a logout option.

Here's what I do. First, at the top of every file in my application, I connect to my database and then have: include("myauthcode.php");

Then, in myauthcode.php the pseudo-code would look something like this:

if ("get" variable is set that indicates that the user just now asked to logout) {
  unset the login session variable;
}
if (login session variable is not set) {
  if ("post" variable is set that indicates that the login form was just now submitted) {
    check against the database;
    SQL error checking...
    if (match found) {
      set session variables;
      /* I also use this opportunity to get some configuration stuff for the user from the DB and keep it in the session too, so I don't have to keep getting it, but if you expect a lot of users logged in at once, that may not be a good idea... */
    } else {
      $message = "<h3 color=red>Invalid UserID or Password.</h3>";  //to be displayed above login form
    }
  }
  if (login session variable not set) {
  /* COVERS TWO CASES: FIRST TIME THROUGH AND FAILED LOGIN */
    echo header stuff;
    echo $message;
    echo login form (with action=$PHP_SERVER['REQUEST_URI'] so that it always comes back to the same page);
  }
}

I don't know if there is a more secure way, but this has worked for me so far (of course, I'm not a bank or something - my data is probably of no interest to hackers anyway). I let PHP sessions do most of the work, and it only needs to go to the database when the user is not already logged in. The session goes away when the browser is closed, and at least in my case it also times out in about an hour or so (I haven't timed it) if not used, but I assume there is a setting for that which I could change (but I don't mind it the way it is, so I haven't bothered to research it).

I hope that helps.

 

[OsakaWebbie]

Oh, and of course session_start() would be at the top of the myauthcode.php file - somehow I omitted that, but I would hope that would be obvious anyway.

 

[bitwise]

Hey OsakaWebbie thank you for your input. I am using a cookie along with sessions because I want the user to be able to come back at another time (e.g. tomorrow) and not have to login again. You can do this with cookies (i.e. set the expiration time), but you can NOT do this with sessions - because session information is destroyed when the browser closes. I'm also using sessions b/c I try to limit any connections to the database at all times. I always seek to avoid unnecessary overhead. Now, you mentioned that you connect to the database every time you load a page. That might be ok, but probably isn't necessary. I connect to the database only when needed, and never randomly, which is not to say that in your scenario this is not needed so I'm not judging.

Thank you for your input. I did take away me some tips around logging out, and error handling among other things.

 

[OsakaWebbie]

...and error handling...

Yes, you always want to check the result variable returned from any DB query - if you try to extract records from a result variable that is simply "false", the response will be unpredictable. I provide a little verbage about what I was trying to do ("Error while inserting address record" or some such thing), the error number, the error description, and the SQL statement I was trying to use, and then exit.

 

[jpadie]

You can do this with cookies (i.e. set the expiration time), but you can NOT do this with sessions - because session information is destroyed when the browser closes

this is an incorrect assertion and should be corrected for future readers.

php propagates its session identifiers to the browser by cookie unless it is told explicitly not to do so.

like any cookie the session cookie can be set to expire at a given time or when the browser closes.

to have a session last a year, say, just place this function call before session_start();

session_set_cookie_params ( time() + (31556926));

as for the old database versus file access argument: it's rarely obvious which will be faster. there are all sorts of variables which can change the answer. however it is rarely important since the latency will be per connection (principally) and compared to the overall latency of the internet, will be entirely negligible in all but the heaviest of recordset retrieval exercises (in which instance the database will beat the file access hands down).