Two sessions in a given script

[NotionCommotion]

Any problems with the following?  Is there a better way to do it?  Thanks

 

<?php


//Use a cookie based session, and read and write to it

session_start();

$_SESSION['foo1']='bar1';

$bla1=$_SESSION['bla1'];


//Get some data from a second session (note that I don't think it matters, but I will not be writing to the second session)

$session_id=session_id();

session_id($_GET['session_id']);

session_start();

$data=$_SESSION['data'];


//Go back to first session.

session_id($session_id);

session_start();


//Read and write to the first session

$_SESSION['foo2']='bar2';

$bla2=$_SESSION['bla2'];


die();


?>

 

[requinix]

Depends. Better way to do what, exactly?

[NotionCommotion]

Access a second session array.

[tryingtolearn]

OK Im curious - what is it supposed to do?

 

I see it resulting in this

Array ( [foo1] => bar1 [foo2] => bar2 )

[requinix]

Access a second session array.

Not that I know. Try not to make a habit out of switching between sessions though.

[NotionCommotion]

 

OK Im curious - what is it supposed to do?

 

I see it resulting in this

Array ( [foo1] => bar1 [foo2] => bar2 )

 

Access a second session.  I've tested the following, however, seem cannot implement session_start() twice.

<?php

//Use a cookie based session, and read and write to it
session_start();
echo('<pre>'.print_r($_SESSION,1).'</pre>');
$data=array();

$_SESSION['foo1']='bar1';
$foo1=$_SESSION['foo1'];

if(isset($_GET['session_id'])) {
    //Get some data from a second session (note that I don't think it matters, but I will not be writing to the second session)
    $session_id=session_id();
    session_id($_GET['session_id']);
    session_start();
    $data=isset($_SESSION['data'])?$_SESSION['data']:array();
    //Go back to first session.
    session_id($session_id);
    session_start();
}

//Read and write to the first session
$_SESSION['foo2']='bar2';
$foo2=$_SESSION['foo2'];

echo('$_SESSION<pre>'.print_r($_SESSION,1).'</pre>');
echo('$data<pre>'.print_r($data,1).'</pre>');
echo("<a href={$_SERVER['PHP_SELF']}>Without session id</a><br>");
echo("<a href={$_SERVER['PHP_SELF']}?session_id=".session_id().">With session id</a>");
die();

?>

[requinix]

You may need to call session_write_close() before starting another session.

 

Also keep in mind that session_id() will cause a new session cookie to be sent, so there'll be one for the second session and another for the first session (when you switch back to it).

[NotionCommotion]

Not that I know. Try not to make a habit out of switching between sessions though.

 

Promise, I will not make a habit of it!

 

My goal...

 

I have three domains:

• bob.public.mysite.com
• bob.admin.mysite.com
• bob.preview.mysite.com

bob.admin.mysite.com generates HTML which creates an IFRAME which points to bob.preview.mysite.com, and includes the session_id of bob.admin.mysite.com in the URL.

 

bob.preview.mysite.com needs to confirm that bob is logged on to bob.admin.mysite.com, and if so, presents HTML for bob.public.mysite.com.  My hopes were to use the session_id in the URL to confirm that bob is logged on to bob.admin.mysite.com.  When attempting to do so, however, I found that the multiple session_starts() were not allowed.  After if confirms, it should return to its original cookie based session.

 

Thoughts?

[NotionCommotion]

You may need to call session_write_close() before starting another session.

 

Also keep in mind that session_id() will cause a new session cookie to be sent, so there'll be one for the second session and another for the first session (when you switch back to it).

 

Thanks requinix,  session_write_close() seems to be the answer.  My webserver is setup using ServerAlias to send all subdomains to the same script.  When a session_id is included in the URL, the following script accesses both the cookie based session as well as the session indicated by the session_id in the URL.  If you see any flaws in my logic, please advise, otherwise I think I am good to go.

<?php

//Use a cookie based session, and read and write to it
session_start();
$session_id=session_id();
$_SESSION['s1_'.time()]=time();
echo('Main session using session_id '.$session_id.'<pre>'.print_r($_SESSION,1).'</pre>');

if(isset($_GET['session_id'])) {
    $new_session_id=$_GET['session_id'];
    session_write_close();
    session_id($new_session_id);
    session_start();
    $_SESSION['s2_'.time()]=time();
    echo('Second session using session_id '.$new_session_id.'<pre>'.print_r($_SESSION,1).'</pre>');

    //Go back to first session.
    session_write_close();
    session_id($session_id);
    session_start();
}

$_SESSION['s1_'.(2*time())]=2*time();
echo('Main session using session_id '.$session_id.'<pre>'.print_r($_SESSION,1).'</pre>');

$domains=explode('.',$_SERVER['HTTP_HOST']);
$ext = array_pop($domains);
$primary = array_pop($domains);
echo('<ul>');
while($domains){
    $domain=implode('.',$domains);
    $link="http://{$domain}.{$primary}.{$ext}{$_SERVER['PHP_SELF']}";
    echo("<li><a href='{$link}'>{$link}</a></li>");
    array_shift($domains);
}
$link="http://{$primary}.{$ext}{$_SERVER['PHP_SELF']}";
echo("<li><a href='{$link}'>{$link}</a></li>");
$link="http://subdomain.{$_SERVER['HTTP_HOST']}{$_SERVER['PHP_SELF']}?session_id={$session_id}";
echo("<li><a href='{$link}'>{$link}</a></li></ul>");
?>

[Jacques1]

Like always, exotic solutions indicate that there's something wrong with the concept itself.

 

Session IDs do not belong into the URL, especially when it's the session of the admin. There's a reason why any halfway competent admin immediately turns off URL-based sessions in the php.ini: URLs parameters are typically written to the server log, they may even be transferred to arbitrary websites through the referrer, and there's a huge risk of people accidentally sharing the secret data.

 

If the preview should (only) be available to the admin, then why is it a separate subdomain of mysite.com? It should be a subdomain of the user's admin domain (or simply a path if the preview is safe). This also makes sense from a logical point of view: The preview is a special service of the admin site. This way the preview is simply covered by the normal admin session. No authentication tricks required.

 

Unfortunately, this is somewhat hard to implement with your current domain scheme. It might make sense to change it to something like this:

public.joe.sites.mysite.com
admin.joe.sites.mysite.com
preview.admin.joe.sites.mysite.com

Of course that means you have to put all domains behind a generic *.mysite.com catch-all and lose the possibility to handle them differently at DNS level. But that shouldn't be a problem.

 

Besides, the code is rather awful. While we discuss about security details, you just dump the user input into your HTML markup with no escaping whatsoever.

[NotionCommotion]

Session IDs do not belong into the URL, especially when it's the session of the admin.

It is not a "real" admin, but I agree with you.

 

If the preview should (only) be available to the admin, then why is it a separate subdomain of mysite.com?

I agree

 

It might make sense to change it to something like this:

 

public.joe.sites.mysite.com
admin.joe.sites.mysite.com
preview.admin.joe.sites.mysite.com

 

What is the purpose of the "site" sub domain (does not "public" or "admin" indicated that it is part of a site?) ?  Earlier we talked about joe.public.mysite.com.  What are the implications of using public.joe.mysite.com instead?  I agree about having preview as a subdomain to admin (and will likely use different session cookie names).

 

 

Besides, the code is rather awful...

Note taking the bait! I know that you know that it was just proof of concept

[Jacques1]

What is the purpose of the "site" sub domain (does not "public" or "admin" indicated that it is part of a site?) ?  Earlier we talked about joe.public.mysite.com.  What are the implications of using public.joe.mysite.com instead?

 

It's still the old problem: If a user chooses a name like “admin” or “payment”, you're in trouble, because now they suddenly control “official” domains like admin.mysite.com or payment.site.com. The “public” prefix in front of it doesn't really help.

 

The point is that the user sites are isolated in a separate subdomain. Of couse it doesn't have to be called “sites”. Choose anything which sounds good and makes it clear that those are user-defined sites.

 

 

 

Note taking the bait! I know that you know that it was just proof of concept 

 

Even then you should not write insecure code. Make security a habit.

[NotionCommotion]

Ugg, when does it end?

 

Assuming Michael is a good guy and he selects "admin" as his admin domain, and the "safe" subdomain is "sites" which the user cannot effect, his sites could be:

michael.public.mysite.com
michael.admin.mysite.com

public.michael.mysite.com
admin.michael.mysite.com

michael.public.sites.mysite.com
michael.admin.sites.mysite.com

public.michael.sites.mysite.com
admin.michael.sites.mysite.com

But, if a bad guy comes along, they could be:

payment.public.mysite.com
payment.secure.mysite.com

public.payment.mysite.com
secure.payment.mysite.com

payment.public.sites.mysite.com
payment.secure.sites.mysite.com

public.payment.sites.mysite.com
secure.payment.sites.mysite.com

Yes, I see a little benefit by putting the "sites" subdomain in.  Which is best assuming we are including the "sites" subdomain?  If we go without the "sites" subdomain, is the answer basically the same?  Would I be best using mysite.com for signup and payment, and mysite.net for all the user's sites?

[NotionCommotion]

Ugg, when does it end?

 

PS.  This was not directed to Jacques1, but to the endless journey to provide secure systems.

[Jacques1]

The difference between “mysite.com” and “mysite.net” is rather subtle, don't you think? In fact, as a user, I'd be very confused if they delivered entirely different content. And I wouldn't expect that one is the “official” domain while the other one hosts the sites of your users.

 

Anyway, you know my position. Whether you agree or disagree is entirely up to you. 

[NotionCommotion]

Not saying I disagree or not, just that there seems to be no perfect solution.  Even if I do it the way I believe you feel it should be done, I have potential URLs like secure.payment.sites.mysite.com which can definitely be phishing abused.

[Jacques1]

The point is that a carefully chosen subdomain actually tells us something about the context of the site. This is very important information. Semantically, there's a big difference between, say, “payment.mysite.com” and “payment.users.mysite.com”. Of course not everybody will notice or understand this. But a lot of people do.

 

The subdomain also prevents users from unintentionally reserving critical names. Even if everybody is nice and friendly, people may still choose a name which you actually want yourself. What now? With an extra subdomain, there's no such problem.

 

Just compare this with a file upload: Do you let anybody place arbitrarily named files directly into your document root? Probably not. I'm sure you have an extra folder just for user uploads. Does this solve all security problems? No, but it's still a very important precaution.

 

The subdomain is one security feature amongst others: Make a blacklist and occasionally check the subdomains to recognize obvious abuse. Restrict the content as much as possible. Consider putting the user sites into visual “frames” to mark them as external content. None of this is perfect, but all features combined do reduce the risk of a phising attack massively.