1 | 2 | 3 | 4 | 5

21 - 23   [23]

PHP Session Management

Also relates to Apache

I have rarely been content with session management in PHP. Since the web is stateless, a session must be maintained on a login site. The optimal way to achieve this is to place a session cookie, in the form of a session ID (a 32 byte alpha-numeric string), on the client. When the client has cookies disabled PHP appends the session ID to the end of each URI on the page. This latter practice comes with inherent complications. Server redirects must have the session ID hard coded into the source, which I sometimes find complicated to manage in complex validation and redirection scripts over multiple pages. Security Focus also highlights the major vulnerability of passing the session ID in the URI for PHP versions prior to 4.3.2.

When testing with cookies disabled I have also found browsing Back a number of pages can inadvertently destroy the session. If not coded carefully, the outcome can be a blank page, leaving the user confused and likely to just leave the site. My opinion is that the safest and most usable solution is to only allow the login process to proceed if cookies are enabled. If they are not a message is presented to the user with recommendations and advice on enabling session cookies and the implications of doing so.

So, the challenge is creating a user friendly process, where the user is informed immediately if they are unable to log in, and directions are given on enabling session cookies. The problem is that when a page first loads, the cookie is only passed to the client, so there is no way of knowing if the cookie has actually been set, and hence whether cookies are enabled. The following code snippet resolves this.


if (! isset($_COOKIE["PHPSESSID"]) && ! isset($_GET["PHPSESSID"]))
{  
  $sess_id = substr(SID,(strrpos(SID,"=")+1));
  $redirect_url = CMS . "init.session_" . $sess_id;
  header("Location: " . $redirect_url);
  exit;
}
elseif (! isset($_COOKIE["PHPSESSID"]) && isset($_GET["PHPSESSID"]))
{  
  $cookies_disabled = true;
}
else
{
  $cookie_disabled = false;
}

First the code tests for the cookie, and if it does not exists it looks for the PHPSESSID variable in the global $_GET array. If the tests fails, then the user has arrived at the page for the first time so it is not possible to tell if cookies are enabled or not. So, a server redirect is done to the same page (here defined by CMS in the initialisation file) with a custom string appended to the end. A custom string is used to enhance security, and the Apache mod_rewrite module is used to rebuild the URI as follows:


RewriteEngine On
RewriteRule init.session_([a-z0-9]{32})$ /cms/?PHPSESSID=$1

When the page reloads it runs the same test again. This time it passes the second condition and will only fail on the first condition if cookies are disabled. At this point a notice can be displayed to the user advising them that cookies must be enabled to actually log-in. To enhance the usability, if $cookies_enabled $cookies_disabled is true, a class is added to the login form, which overrides the normal CSS declarations, disabling the input fields and striking out corresponding labels. To aid users of assistive technologies, a title is also appended to each label stating that fields are disabled because cookies are required.

Perhaps this is common practice, but I recall in the past having trouble finding useful information for PHP session management best practices, and this seems to be an effective approach. The whole process is transparent to the user, and incorporating mod_rewrite to cloak the session id raises the level of security for the initial server redirect in which it is passed, as well as replacing the aesthetically displeasing URI string:

http://mysite/login/?PHPSESSID=sessionid

with the more comprehendable:

http://mysite/login/init.session,sessionid

If the initialisation variable session.name is changed to something other than PHPSESSID (or session_name(string) is called) then the URI becomes much harder to hack.

Posted on Nov 10, 2003 at 02:19:13. [Comments for PHP Session Management- 6]

Java/PHP Bridge

Also relates to Java

This months PHP|Architect sample article gives a quick guide to Installing Java for PHP. The PHP manual suggest the method applied, of integrating Java into PHP, is not as stable as reversing the roles, and integrating PHP into a Java Servlet. All the same, finally get to use that Java DLL in the PHP extensions folder. Note the article does fail to emphasise that java.class.path must be quoted when including the path to custom classes, which did lead to a few minutes of hair tearing!

Posted on Sep 12, 2003 at 22:31:36. [Comments for Java/PHP Bridge- 2]

A Few Quick TitBits

Also relates to Accessibility and Peregrinations

Been very busy the past couple of weeks, so not much time for blogging…Here's a few bits and pieces from around the web…

  • Need to hone those Photoshop skills? I rediscovered some handy tricks within Janee's Photoshop Tutorials.
  • The new Accessify.com Forum is well and truly active and already looks set to be the topical place for accessiblity-minded developers.
  • What's it like to be without power for 29 hours…Let Zeldman tell you.
  • The best Chicken pie I have had for a long time, and a picturesque setting at the Saracen's Head.
  • After a quick perusal of the PEAR IT/ITX modules for templating, finally dived into Smarty to speed up some CMS based PHP development and to avoid mainifesting globular chunks of XHTML within the API.
  • A good starting point for developing DOM based Client Side Table Sorting scripts.
  • The main set of Chrome URLs for Mozilla and Firebird (Still using it and loving it!)
  • XForms is getting ever closer to REC status, and what a difference it will make to the laborious task of developing user forms. Of course you can easily test the benefits and potential in X-Smiles Java Browser during the inevitable laborious wait for implementation in the main player…
  • Symantec's ever efficient security response to that sneaky critter lurking the web. Some friends fell foul within 48 hours of Blaster's release, and we had an arduous clean up session over the phone. Of course if your infected, you probably will not be reading this, at least not beyond the page title!!! At least XP users now know they are not 100% secure, as a certain corpora$ion would make them believe!
  • Oh, and in less than 10 days I will finally be able to see what happens in the last 15 minutes of the Two Towers following an unexplained shut down of the cinema last Christmas. Still scouting for the official release of the RotK Trailer…

Posted on Aug 17, 2003 at 21:20:43. [Comments for A Few Quick TitBits- 0]

Breadcrumbs Trail

[ Home ] -> TW Blog -> PHP
Site Map

The Severn Solutions website achieves the following standards:

[ XHTML 1.0 ] [ CSS 2 ] [ WAI AA ] [ Bobby AA ]

Page compiled in 0.134 seconds