I have developed a site that stores most data in the session object. We now have to implement a payment function that works over SSL. The secure pages are hosted on another server and we have no control over this. The result is that when we try to access data from these pages, they are running under a new session so they can't see the data we've already created. For example, items are added to a shopping cart in a non-secure portion of the site. The "check out" page, however, is secure and so it runs under a different session.
What I need to know is if there's any way to force a page to run in the same session or if there is any other way to communicate between sessions. I have tried to post data between pages and also tried to use cookies, but this doesn't seem to work either. Any input on this would be GREATLY appreciated.
Sharing Data Between Multiple Sessions
Moderator: General Moderators
-
ryanwpatterson
- Forum Newbie
- Posts: 6
- Joined: Wed Sep 17, 2003 10:10 am
- Location: Austin, TX
I'm just shooting in the dark, as I don't know much if it really would help... (Or is safe enough at all...)
You can, use the $_GET to ship data in the URI. Downside to that is that it is likely to visible to the user...
Simulating a $_POST should work also (hidden fields, javascript sending it, whatever), but as you allready tried this I'm wondering...
I'll try this too if I don't have to much work to do.
In either case, it should work (and be safe enough) if you add some serious crypting to it.
Good luck. Let us know how it turns out as my personal interest is also involved now...
You can, use the $_GET to ship data in the URI. Downside to that is that it is likely to visible to the user...
Simulating a $_POST should work also (hidden fields, javascript sending it, whatever), but as you allready tried this I'm wondering...
I'll try this too if I don't have to much work to do.
In either case, it should work (and be safe enough) if you add some serious crypting to it.
Good luck. Let us know how it turns out as my personal interest is also involved now...
I just tried it. Tho i have no secure server as you do per se, but the $_POST as I think you meant to use it worked.
Do comment.
Do comment.
Code: Select all
// index.php, locally
<?php
session_start();
$_SESSION['foo'] = 'FOO';
$_SESSION['bar'] = 'BAR';
$sending = base64_encode(serialize($_SESSION));
echo '<pre>';
print_r($_SESSION); // debugging
?>
<form method="post" action="http://php.jam.nu/test.php">
<input type="hidden" name="session" value="<?php echo $sending; ?>">
<input type="submit" name="send" value="Continue">
</form>Code: Select all
// test.php, at host
<?php
// print_r($_POST); // debugging
session_start();
session_unset(); // just in case...
session_destroy(); // just in case...
$_SESSION = unserialize(base64_decode($_POST['session']));
echo '<pre>';
print_r($_SESSION); // debugging, results
?>-
ryanwpatterson
- Forum Newbie
- Posts: 6
- Joined: Wed Sep 17, 2003 10:10 am
- Location: Austin, TX
Well, I was sorta limited as to what I could do because the hosting company sets all the configuration options. So, the way I worked around this for now (I intend to devise a better solution for the next release) was to add a function to my shopping cart object that stores the cart data to the database using the session id as the primary key. Then, when I simply post the session ID to the secure page, create a new shopping cart object, and restore the data from the database. So, every time the user hits the payment page, they are actually seeing a copy of the shopping cart that was created in the non-secure session.
I like JAM's idea. I do some hosting for people who do OSCommerce and this is a problem using shared SSL. It bites up all of the IP's to give them each an SSL.
If we take the cookie values for the cart from the non ssl page and then encrypt them using mcrypt/3des and then post is to a special recieving page on the SSL server that descrypts them and then passes you onto the next page it should work fairly well. The post can then be a get/post request because the string is encrypted (remember to pad with timestamps and delimiters
).
The end result is that the session id (or cart id) is the same on both servers because the cookie has been set as such.
BTW, you should be storing the cart in the database. Avoid the sessions that way to can load balance in the future.
If we take the cookie values for the cart from the non ssl page and then encrypt them using mcrypt/3des and then post is to a special recieving page on the SSL server that descrypts them and then passes you onto the next page it should work fairly well. The post can then be a get/post request because the string is encrypted (remember to pad with timestamps and delimiters
The end result is that the session id (or cart id) is the same on both servers because the cookie has been set as such.
BTW, you should be storing the cart in the database. Avoid the sessions that way to can load balance in the future.