Table of Contents

Session Types

By: Pablo Fischer (pablo@pablo.com.mx)
Email: pablo@pablo.com.mx

Introduction

Before reading and article you must read the documentation we already have about Omni, our session management system.

If you have ever developed web applications you must know that you can create many ‘fronts’ for your application, you can focus on the web view (what you see in your browser) or you can also create others views for webservices using SOAP, REST or XMLRPC.

However there’s a problem when you write this kind of applications, the problem comes when you have users and you want those users to authenticate. User authentication is the easy part, but it gets difficult when you want to have sessions in your application. You want your users to have their session opened/closed.

Jaws currently allows multiple sessions, for example: the user can create another session form another web browser. In web browsers Jaws only needs a cookie with a SESSION ID, with this ID Jaws will try to load the old session (only if the ID already exists).

But what happens when you write a webservice with SOAP?. Telling the user to send his SESSION ID is not friendly, the SESSION ID is a md5 key. So, whats the solution for this? Session Types.

With session types the user doesn’t needs to send the SESSION ID all the time, the user only needs to send the username and password to be authenticated, once the user is autenthicated Jaws will know which type of Application the user is using (web, soap, rest, etc). With the Application Type, Jaws will try to find a session type for the user, if there’s already a session for SOAP (for example) Jaws will use that, if there’s no session then Jaws will create it.

Some Code

Maybe some code will be usefull to understand all this crap.

The database table for sessions will be changed to:

CREATE TABLE session (
  session_id varchar(128) NOT NULL DEFAULT '',
  user_id int(11) NOT NULL DEFAULT '0',
  type varchar(20) NOT NULL DEFAULT 'web',
  creation_time int(16) NOT NULL DEFAULT '0',
  modification_time int(16) DEFAULT '0'
) TYPE=MyISAM;

So, everytime the user creates a new session the session type will be used only for web (web browsers), but Jaws can change the type just telling which session type it will be: web, rest, soap, etc.

In PHP code it will be very easy, the application type will be managed in the $GLOBALS[“app”] object.

$GLOBALS["app"] =& new JawsApplication ();
$GLOBALS["app"]->Create ($db['user'], $db['password'], $db['name'], $db['host'], $db['driver'], $db['prefix']);

Then, in the index.php and admin.php files (that are used only for the web view) it should exists:

$GLOBALS["app"]->SetApplicationType ("web");

With this, JawsSession will know which type of session type should be used by just asking it to JawsApplication (GetApplicationType).

But hold on, currently we have a JawsSession that uses cookies, we don’t want to deal with cookies in webservices (although its possible we don’t want it, we don’t trust too much in cookies). So, how to tell JawsSession when to use cookies?. There are two posible solutions for this:

  1. Use lot of conditionals in JawsSession.
  2. Divide and conquer: we can have many kinds of JawsSessions: WebJawsSesssion, SOAPJawsSession, etc. Each one will be a separated class and must inherit from JawsSession. These JawsSessions will be located in a directory called SessionTypes inside the include directory.

The best solution is the second one.

 
  /var/www/wiki/htdocs/data/jaws/proposals/sessiontypes.txt · Last modified: 2007/11/02 16:27