Can I share Session variables between multiple clients with php Sessions?

Question

what I am trying to find out is, if I can share a Session variable for multiple clients. Like they can use the exactly same Object. The below example will illustrate what I would like to do.

client1:

start_session();
include('somelcass.php');
//some code...
$someobj = new someclass();
$_SESSION['myobject'] = serialize($someobj);
$id = sha1("somephrase");
set_session_var_for_other_users_by_id('myobject', $id);

client2:

start_session();
include('somelcass.php');
$id = sha1("somephrase");
get_sessionvars_from_other_users($id);
$someobj = unserialize($_SESSION['myobject']);
//now use someobj from class someclass

And my additional question is: Do you recommand using some session extention like: sessionPsql

Answer 1

Answering your last question first:

The Session PgSQL^Docs you linked is the PostgreSQL Session Save Handler. It is a Session Save Handler you can configure to use instead of the default session save handler. The default session save handler in PHP is storing sessions to disk (files). If you use the save handler for PostgreSQL sessions are saved into a PostgreSQL database instead (pgsql).

Saving sessions inside a database can make sense if you want to allow access to the session store from multiple webservers (scaling an application) or in your case (probably) to access all sessions with SQL queries albeit normally a tailored session save handler is defined for that (which could be based on the PgSQL session save handler functions).

To answer your first question then:

Yes you can do so as long as you've got a reference to the object you relate to and you know how to access it. This can be either done by manually accessing the session storage or by sharing a session on it's own and switching sessions to access other session data. It depends on your needs, in your case it's probably more easy to just access serialized data that is stored by the ID in some extra table that has nothing to do with sessions. You should think about how to take care of the data if you don't need it any longer, e.g. remove it after some time of inactivity. In the end you're writing your own session implementation that way which is do-able. PHP before version 4 had no session support out of the box and the session support it has nowadays is very lightweight so if you need to do more specific stuff like you need to do, you normally write your own.

So multiple clients can use the same session (share a session) which is actually as well a way to attack webapps (session hijacking^Attack) but as long as the "hijack" is intended inside your application data-flow, I do not see anything technically wrong with it. In PHP that means you need to close the current session, open the other one (sessions are identified by their name and ID), read the value, close the other session and re-open the current one. It technically works in PHP however write solid code when you do this because session problems are quite hard to debug.

This is also often a good reason to write your own object-sharing mechanism between multiple clients instead of re-using PHP's session feature^Docs for that.