[SOLVED] Quickie: $_SESSION and the concept behind it...

[webmaster1]

Hi All,

 

I'm using the global $_SESSION function to allow the user log into an admin page:

 

if ($username == $valid_username && $password == $valid_password) {
$_SESSION['logged'] = true;   

 

Each page that I want password protected checks if the session is logged.

 

session_start();
if (!$_SESSION['logged'])

 

This all seems to work as desired but I'd like to know if this is actually the case.

 

How does the session know to stay logged as I navigate from page to page and how does it know to end?

 

 

 

[.josh]

well I'm hoping that that's pseudo-code. In actuality it would look more like this:

 

<?php
session_start();
if (!$_SESSION['logged']) {
   header("Location: login.php");
   exit();
}

// rest of your code here

 

And you'll know it works because the only time you create the session variable is if the user logs in and the name/pw matches.  If they didn't go through the login.php and match the name/pw combo, then $_SESSION['logged'] wouldn't exist, and if it doesn't exist, user gets redirected to login script.  Or you could log the access attempt or whatever else you like, inside that condition.

 

Read up on how sessions work to understand how the session variable gets carried from page to page. 

[webmaster1]

Yep, thats only snippets of the code. I have it functioning already:

 

<?php
session_start();
    $valid_username = "foo";
    $valid_password = "bar";

    $username = isset($_POST['username'])?$_POST['username']:"";
    $password = isset($_POST['password'])?$_POST['password']:"";

    if ($username == $valid_username && $password == $valid_password) {
          $_SESSION['logged'] = true;   
         header("Location: adminhm.php");
    }else {
             $_SESSION['logged'] = false;
             header("Location: invalid.html");
    }
?>

 

I was just wondering how it all actually works. Is it cached in a file in my browser somewhere?

 

I'm not using a database because I just have the one password btw.

 

I've come across this:

A PHP session solves this problem by allowing you to store user information on the server for later use (i.e. username, shopping cart items, etc). However, this session information is temporary and is usually deleted very quickly after the user has left the website that uses sessions.

 

 

[Mchl]

When you create a session, the script sets up a cookie on users computer, with so called session ID. The script can access this cookie (and ID) and based on that, can access a file on server's hard disk where all session variables are stored.

[.josh]

Basically when you start a session a session id is generated.  By default it is randomly generated and stored as a cookie on the client.  You do have the ability to specify your own session id, as well as regenerate it.  You can also pass the session id through the url via the GET method (like you did with page.php?foo=bar in one of your earlier threads) to keep the session alive, if the user has cookies disabled. 

 

The session variables are stored in a special folder on the server.  On a shared server everybody's session data is stored in the same place.  Since it is possible to set a specific session id, it is conceivable that you can use a rainbow table or some other algorithm to assign random session ids and do a $_SESSION vardump, accessing other people's sessions on the shared server. 

 

Now, that isn't as scary of a thing as it sounds.  For one thing, the id is encrypted.  It's pretty hard to decrypt it.  But regardless, if it makes you sleep better at night, you also have the ability to specify your own place where session information is stored. 

 

So anyways, the actual session variable:data is stored on the server in a flatfile, and the session id is used to access it, and the name of the session variable is used to find the data associated with it.  In principle, it more or less works like a flatfile database (except no fancy queries with sort bys or limits or joins or anything), except that when you close your browser, the cookie is automatically destroyed, thus ending the session on the client-side.  Also, if there is no session activity (page requests with session_start) for x amount of time, the session times out.  I'm not 100% sure but I think you can set the timeout length in php.ini or somewhere, and I think the default timeout is like 9 minutes or something. 

 

You can also in your script unset session vars and manually destroy a session.

[webmaster1]

when you close your browser, the cookie is automatically destroyed

 

Perfect. I wasn't sure when it ended.

 

if the user has cookies disabled.

 

One more question on this: Is it considered best practice to keep the session alive using GET? In other words will I get away with not catering for those with disables cookies because its not a liklihood?

 

I've noticed that IE will sometimes prompt "cookies must be enabled for this site". Is this an automatic prompt?

[Mchl]

PHP uses GET method for sessions automatically when the browser has disabled cookies.

 

The prompt you're talking about is not automatic... but sites that can not run without cookies are... well... bad. Once you have session, you have no need for cookies. Unless you want to store inforamation between user visits.

[webmaster1]

Unless you want to store inforamation between user visits.

 

Great, no need then for this scenario. I think I'm going to grow lazy and fat on these global functions.

[.josh]

Kind of losing focus but...right.  Treat cookies in general like javascript or ajax.  Something to enrich your site, but do not depend on them for your site to function.

[webmaster1]

Treat cookies in general like javascript or ajax.  Something to enrich your site, but do not depend on them for your site to function.

 

If Lao Tzu (Father of Taosim) was a PHP Freak he'd probably have put it exactly as above. It sounds like a Zen-like metaphor for life. 

 

I take pearls of wisdom like these and intermittantly paste them into my scripts as comments.

 

[Mchl]

He was PHP Freak you know... Has published great book with O'Reilly