Php Sessions are used to help maintain the values of variables across multiple web pages.
This is done by creating a unique session ID that is sent to the client browser.
The browser then sends the unique ID back on each page request and PHP uses the ID to fetch the
values of all the variables associated with this session.
The session ID is sent back and forth in a cookie or in the URL. By default, PHP tries to use cookies,
but if the browser has disabled cookies, PHP falls back to putting the ID in the URL.
The
php.ini directives that affect this are:
session.use_cookies
When on, PHP will try to use cookies
session.use_trans_sid
When on, PHP will add the ID to URLs if cookies are not used
The trans_sid code in PHP is rather interesting. It actually parses the entire HTML file
and modifies/mangles every link and form to add the session ID. The url_rewriter.tags php.ini
directive can change how the various elements are mangled.
Writing an application that uses sessions is not hard. You start a session using session_start( ),
then register the variables you wish to associate with that session. For example:
<?php
session_start( );
session_register('test');
session_register('test1');
$test = "Hello";
$test1 = "World";
?>
If you put the previous example in a file named page1.php and load it in your browser, it sends you a cookie and stores the values of $foo and $bar on the server. If you then load this page2.php page:
<?php
session_start( );
echo "test = $_SESSION[test]<br />";
echo "test1 = $_SESSION[test1]<br />";
?>
You should see the values of $foo and $bar set in page1.php. Note the use of the $_SESSION superglobal.
If you have register_globals on, you would be able to access these as $foo and $bar directly.
You can add complex variables such as arrays and objects to sessions as well. The one caveat with
putting an object in a session is that you must load the class definition for that
object before you call session_start( ).
A common error people make when using sessions is that they tend to use it as a replacement for
authentication -- or sometimes as an add-on to authentication. Authenticating a user once as he first
enters your site and then using a session ID to identify that user throughout the rest of
the site without further authentication can lead to a lot of problems if another person is somehow
able to get the session ID.
There are a number of ways to get the session ID:
If you are not using SSL, session IDs may be sniffed
If you don't have proper entropy in your session IDs, they may be guessed
If you are using URL-based session IDs, they may end up in proxy logs
If you are using URL-based session IDs, they may end up bookmarked on publicly-accessible computers
Forcing HTTP Authentication on each page over SSL is the most secure way to avoid this problem, but it tends to be a bit inconvenient. Just keep the above points in mind when building a web application that uses sessions to store users' personal details.