> From: Bob Mariotti
> Sent: Saturday, July 22, 2006 1:11 PM
>
> The user would access the entry page with www.a.com and from
> there the index would ultimately deliver program.php which
> would interact with the user for any number of functions.
> Eventually
> we will need to capture some sensitive information that MUST
> be secured. It MUST be served on this particular server and
> therefore the
> SSL secured site is b.com. What technique would YOU use to transfer
> the user, along with his "session" to the b.com server to do
> its thing, and then get control back to the a.com server
> keeping the session intact?
That's not really anything to do with PHP, it's just a general web authoring question.
A assume that you are trying to submit a form from the SSL page to the non-SSL page and avoid a browser warning message, since that's the only tricky scenario that I can think of.
To avoid the warning, the action of any form loaded through SSL needs to point to an SSL page. If you want to get back to a non-SSL page, you need to make the transition that does so not be a form submission.
One simple way to do this if your form is submitted via GET is to simply do a redirect from an SSL submit target to the ultimate non-SSL page you want to get to and pass along the query string:
a.php:
------
<html>
<body>
<form action="https://b.com/b.php" method=get>
<p>Got: <?= $_REQUEST["submit"] ?></p>
<input type=submit name=submit value="Submit to B">
</form>
</body>
</html>
b.php:
------
<html>
<body>
<form action="https://b.com/c.php" method=get>
<p>Got: <?= $_REQUEST["submit"] ?></p>
<input type=submit name=submit value="Submit to A">
</form>
</body>
</html>
c.php:
------
<? header("Location: http://a.com/a.php?" . $_SERVER["QUERY_STRING"]) ?>
If you are doing submitting via POST you can't really apply this method quite so simply because browsers change a POST into a GET in response to a normal redirect. There is a newer redirect status, 307, that is supposed to fix the issue, but it is not supported by hardly any browsers at this time.
I think your best bet if you must POST is to store the data server-side in the SSL form target page and let the receiving non-SSL page that you redirect to pick up the stored data based on a key passed in a cookie or the query string.
Simplest of all is to avoid the situation all together and just link back to the non-SSL page if you can.
David
More information about the ECLUG mailing list