PHP Advent Calendar Day 4
04 Dec 2007Today's entry is provided by James McGlinn.
- Name
- James McGlinn
- Blog
- blog.phpdeveloper.co.nz
- Biography
- James McGlinn is the CTO of Eventfinder (a major New Zealand entertainment site) and founder of the NZ PHP Users Group, now 500 strong. He is a member of the PHP Security Consortium and helps maintain user notes for the PHP documentation.
- Location
- Auckland, New Zealand
In keeping with the Advent calendar theme, this entry touches on one aspect of the festive season that's difficult to miss. Shopping. Particularly online shopping and making sure the online payment experience is a safe and secure one for your visitors.
One aspect of online shopping that can be difficult to manage is making sure that your sensitive pages are correctly served by the secure server, without slowing your site (and your visitors' experience) down by serving pages over SSL that needn't be.
If you have only one or two pages that need to be secure (the checkout for example), it seems straightforward enough to simply specify absolute links to those pages on the SSL server. But how about when you add a few more secure pages (the login screen, admin system, or perhaps an alternate checkout for affiliate sales)? And, how do you redirect back to the non-secure server when your user navigates away from the checkout system, in order to increase responsiveness and reduce server load? Not to mention the headache that working with absolute (instead of relative) URLs brings to the development process.
The simplest answer to all of these issues is to create a single script, called within the header of your online store pages, to detect whether the page requested should be secure, and redirect to the appropriate server if necessary.
First, set up your configuration:
<?php
$hosts = array(
'secure' => 'shop.mydomain.com',
'nonsecure' => 'mydomain.com',
);
$secure_pages = array(
'/checkout/',
'/login.php',
'/admin/',
);
?>
The first array contains the hostnames for your secure and non-secure servers (assume both share the same document root). The second array contains a list of the directories or specific resources that must be served from the secure server. Non-secure requests that start with one of these strings will automatically be redirected to the secure server.
On to the code itself. First, we check the request against our list of secure pages and redirect to the secure server if necessary:
<?php
$clean = array();
// Prevent whitespace characters in URL.
if (ctype_print($_SERVER['REQUEST_URI'])) {
$clean['request_uri'] = $_SERVER['REQUEST_URI'];
} else {
$clean['request_uri'] = '/';
}
if (empty($_SERVER['HTTPS']) && count($_POST) < 1) {
// Not using SSL and not posting data, so check if we should be using SSL.
foreach ($secure_pages as $secure_page) {
if (substr($clean['request_uri'], 0, strlen($secure_page)) == $secure_page) {
$new_url = sprintf('https://%s%s', $hosts['secure'], $clean['request_uri']);
header('Location: ' . $new_url);
exit;
}
}
}
?>
This will redirect visitors transparently to the secure server, safe in the knowledge that their credit card details can't be intercepted en route to your store. But, what about when the checkout process is complete, or they abandon the procedure part way through to add last minute items to their Christmas basket of goodies? By adding to the code above, we can redirect users still on the secure server back to the non-secure server as required:
<?php
elseif (!empty($_SERVER['HTTPS']) && count($_POST) < 1) {
// Using SSL and not posting data.
$dont_redirect = FALSE;
foreach ($secure_pages as $secure_page) {
if (substr($clean['request_uri'], 0, strlen($secure_page)) == $secure_page) {
$dont_redirect = TRUE;
}
}
if ($dont_redirect === FALSE) {
// Redirect.
$new_url = sprintf('http://%s%s', $hosts['nonsecure'], $clean['request_uri']);
header('Location: ' . $new_url);
exit;
}
}
?>
This will redirect the user back to the faster non-secure server for those requests where security isn't an issue, without any more intervention on your part.
You'll notice in each of these code samples that we don't automatically redirect POST requests. This is because any data accompanying the POST request would be lost. I leave it as an exercise for you to determine what should be done in that instance and handle the condition accordingly.