I just got done reading a bunch of threads on this topic after using the search on this site, however my problem still exists.

I'm having problems transferring session information from a secure site (www.mysecuredomain.com) to a non-secure site (www.mynonsecuredomain.com). These scripts are both on different domains which means I have to transfer the session id in the URL and/or a hidden form variable.

I wrote a simple script to test this which initializes a session and sets a single session variable called "username" equal to "testUser".

<?

session_start();
$_SESSION['username'] = "testUser";
header("location: [url]http://www.mynonsecuredomain.com/testsess2.php?sess=[/url]" . session_id());

?>

The script on the non-secure site looks like this...

<?
if($GET['sess'])
{
$session = $
GET['sess'];
session_id($session);
}
session_start();
?>
<html>
<body>
<?
echo $_SESSION['username'] . "<br>";
echo session_id();
?>
</body>
</html>

The session id is pulled from the URL and set just fine, however no username is printed out on testsess2.php. This tells me that none of the session data got transferred.

Does anyone have any idea why this is happening and what can I do to fix it? Thanks for the help.

  • Brad

    Sessions work by using a temporary file on the server which isn't deleted at the termination of your script and contains all the session data you save. This session file is referenced using a unique ID. The server sends this ID (not the data itself) to the client in a cookie - on any further requests the client sends the cookie back to the server which can then identify the relevant temp file and retrieve the session data and everything works swimmingly.

    The problems you may have are twofold:
    1) Cookies by default are specific to a single domain for security reasons. You want the cookie to be send with requests for the HTTP and HTTPS domains which are different. In order to overcome this you can use the session_set_cookie_params() function to change the session.cookie_domain directive in your script and set the cookie to be readable from both the domains you're using.
    2) This will of course only work if both the HTTP and HTTPS domains are run from a single server using the same temp directory otherwise the second server will get the cookie but have no temp file relating to the ID in it and hence no session data. If this is the case you will have to develop a work-around to transfer the data.

    Hope that helps!

      Having just re-read your post I see you're not using cookies to transfer the session ID which rules out the first solution - what you need to look now is where the temporary session files are being stored - you can override this with the session.save_path directive (see http://uk2.php.net/manual/en/ref.session.php#ini.session.save-path) - you need to make sure the file is readable from the servers of both domains.

        Thank you for your response!

        These are two completely different servers, so when the session id is passed from one domain to the other (via URL), is all of that session information passed as well?

        Even if the session save path is set the same on both servers, is the session file transferred along with the session id and recreated on the new server?

        Is this a common problem with PHP sessions? Would purchasing a non-shared SSL certificate help at all since the certificate would keep everything on the same server as opposed to two different servers?

        Ideally, what is the best solution for this type of problem?

        Again, I appreciate your reponse. Thanks a bunch.

        • Brad

          Hi

          If these are two separate servers then you have a problem. No information is passed automatically other than the session_id. It is unlikely you're going to be able to get two servers to use a common session file - I was thinking it might be one physical server which might have been simpler.

          Come to think of it you may be able to use a database to store your session data (see the section on session handlers) which (assuming it was accessible to both servers) could then work. In reality this may be tricky to set up and I've never done it so can't advise how.

          Alternatively getting an SSL certificate for your domain would solve all this problem very simply and probably look a bit more professional that using a shared SSL server.

          Good luck!

            Another approach:
            Just install your scripts on both servers. Only use a one database server.

            Make a scripts than sincronize your scripts server.

            This works because I use it. even with a firewall.

              my suggestion (which was actually quadmyre's) is to stuff your session into a temp database table whenever moving between HTTP and HTTPS using the session_id as the unique identifyer. i would [man]serialize[/man] the $_SESSION array, stuff in it a TEXT field and then pull it back out and [man]unserialize[/man] on the other side.

                just thinking more about this. if the HTTP and HTTPS domains are on the same machine then you would not need to employ the database idea explained above. you simply need to propagate the session ID via the URL. PHP's trans_id scheme will not work because according to the manual...

                Non-relative URLs are assumed to point to external sites and hence don't append the SID, as it would be a security risk to leak the SID to a different server.

                ...which makes perfect sense. since going from HTTP to HTTPS would be a non-relative URL (even if it is the same physical machine) the trans_id will not be appended. if this case you would to append it manually:

                echo '<form action="https://www.securedomain.com?' . session_name() . '=' . session_id() . '">';
                

                if the 2 domains are on 2 different servers then you must find alternate ways of session storage (ie. database).

                  Write a Reply...