SSI isolates $_SESSION?

[Egroj]

Hi!

I'm working on integrate SMF into my Single Sign On system. This means that I have a script which calls the SSI and sets some session variables, which should then be read by a mod.

But it isn't working. I've found that the mod can't find the variables which were written by de SSI script. I've been searching for the problem and I've found that SSI isolates $_SESSION.

I have concluded it with the next experiment. I have foo1.php, which just sets some session variables. foo2.php, which shows all the session variables, I execute both of them and I check that it's working. Now, I include ssi.php in both scripts, and it works too. But if I include SSI in just one of them, I find different session variables. Even when I have made sure that session_id is the same in all the cases.

Back to my project. I need my SSI script to share session variables with my mod. Is there any solution or I should change my system?

Thank you

[Egroj]

Ok, I have developed a litle hack to manage this. This is the code, each one should adapt it to its own situation, this is out of SMF context as you can see in SQL connections...

I have added a table called "isolated_session" and two functions (which I have written in the end of this message). When I want to manage $_SESSION in my isolated context, I execute:

Code Select Expand

global $original_session;
$original_session=$_SESSION;
unisolate_session();


And $_SESSION has now the items which are stored in the database. I can manipulate the session. And then, when I want to come back to the normal situacion I execute

Code Select Expand

isolate_session()

And the session comes back to its original state.

The main goal of this system are that I can share $_SESSION variables between SMF usual context and SSI context for a short time (I suppose that SSI isolates $_SESSION because of security reasons, which I can't understand). Moreover, I haven't to change the libraries of my SSO system, which usually calls $_SESSION variables.

My two funcions to isolate and unisolate my $_SESSION variables:

Code Select Expand



function unisolate_session()
{
global $smfconnect,$db_prefix;

$sql="SELECT `VALUES` FROM `".$db_prefix."isolated_session` WHERE `PHPSESSID`='".session_id()."' LIMIT 0,1;";
$r=mysql_fetch_row(mysql_query($sql,$smfconnect));
if (!$r){return;}
$sql="DELETE  FROM `".$db_prefix."isolated_session` WHERE `PHPSESSID`='".session_id()."';";
mysql_query($sql,$smfconnect);
$add_variables=unserialize($r[0]);
$aux=array_merge($_SESSION,$add_variables);
$_SESSION=$aux;
}

function isolate_session()
{
global $smfconnect,$db_prefix;
global $original_session;

$aux=array_diff($_SESSION,$original_session);
$aux=serialize($aux);
mysql_query("INSERT INTO `".$db_prefix."isolated_session` (`PHPSESSID`,`VALUES`) VALUES ('".session_id()."','".$aux."');",$smfconnect);

$_SESSION=$original_session;
}

[Deprecated]

You need to include session_start() at the beginning of each script that is using the session.

http://us3.php.net/session_start

[Arantor]

Or you could just load SSI.php before anything else which will auto initialise SMF's session handling in its entirety, and then use *that* as your single sign on...

[Egroj]

I deleted the experiment's files, but I'm sure I tried to execute session_start() at the beginning of the script (Maybe executing it before or after calling SSI might mark the difference?). If I have some time later I'll repeat my experiment and I'll upload the source. I'm almost sure that SSI isolates session variables.

Arantor, are you suggesting to call SSI from a code fired by the index? I thought about it, but it doesn't sound as a good idea, I think. I can't start session with the SSI because it asks for a password, and my users have yet written their password in the SSO login form.

The SSO is working almost fine, I'm testing it right now.

[Arantor]

Um, yes, that's how it's supposed to be used...

Given the very limited details you've given, I see no reason why you can't just use SSI to do *everything* and have SMF actually handle logged in status in its entirety. After all, SMF's login system is mature, hardened against things like session fixation and whatnot, and I doubt anything I can build off the bat would be as hard without a lot of time to mature and prove itself.

Once SSI.php is loaded, ideally first, you will have access to the logged in status of the current user straight away. There are options directly in SSI.php for showing a login form to the user which allows them to log in and be redirected back to whatever page you want them to go to once being logged in, too.

[Egroj]

I can't use SSI native login form because the login is supposed to be done from another domain.

Finally I created my own Session variables system, isolated from PHP one. And obviously the problem is yet out.

[Kindred]

you really can't do that (and shouldn't do that)
for very basic security reasons, you should not even be trying to set a session across domains.

[Egroj]

No. My system is not that simple. The session is controlled from the server, just as other systems. A session cookie is set in the browser for each domain and the server validates or not that cookie while the page is loading. Of course, there's a shared database between all domains.

To set cookies in all domains I use jsonp querys, which don't contain real data (it might be changed by the client) just a random token to find the information in the database.

It's just as secure as any other system using cookies. I suppose that you told it's insecure because you assumed that I was starting sessionin a way that any user might send and http request and be logged in or something like that. Now you know some more details, if you really find my system insecure I'll read you. Thank you.