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('foo'); session_register('bar'); $foo = "Hello"; $bar = "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 "foo = $_SESSION[foo]<br />"; echo "bar = $_SESSION[bar]<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.