[FIX] SSL link loops -> timeout
Posted: Thu Jul 09, 2009 11:04 pm
This one cropped up here:
http://www.interspire.com/forum/showthread.php?t=13676
Version
5.0.0 ? - 5.0.5 (not 4.x)
Symptoms
Every time someone tried to create an account or login or went to any of the pages where the secure part of the site should kick in, it went into a loop that never finished. QED: No customers no sales, lots of tears...
Cause
The problem is caused by the host apache setup rewriting the [HTTP_HOST] component in the $_REQUEST headers so that it includes the SSL port "443" as a distinct part of the string instead of leaving it under the [SERVER_PORT] header.
The Interspire Shopping Cart code does some checking of the request or posted URL when it thinks it should be secured but unfortunately it assumes that if the host header is not the same as the host component in the $ShopPath configuration variable then it fails.. This includes if there's a port tagged on the end.
The Solution
Open: /lib/ssl.php
Find:
Replace with:
If anyone can point to where the Apache config may be out of whack and provide a more permanent fix for the host provider that'd be appreciated... I'd like to know what could cause such a scenario for curiosity sake if nothing else.
http://www.interspire.com/forum/showthread.php?t=13676
Version
5.0.0 ? - 5.0.5 (not 4.x)
Symptoms
Every time someone tried to create an account or login or went to any of the pages where the secure part of the site should kick in, it went into a loop that never finished. QED: No customers no sales, lots of tears...
Cause
The problem is caused by the host apache setup rewriting the [HTTP_HOST] component in the $_REQUEST headers so that it includes the SSL port "443" as a distinct part of the string instead of leaving it under the [SERVER_PORT] header.
The Interspire Shopping Cart code does some checking of the request or posted URL when it thinks it should be secured but unfortunately it assumes that if the host header is not the same as the host component in the $ShopPath configuration variable then it fails.. This includes if there's a port tagged on the end.
The Solution
Open: /lib/ssl.php
Find:
Code: Select all
if (is_array($shop_url) && $shop_url['host'] != $host) {
// redirect if not correct host
$location = GetLocation();
ob_end_clean();
header("Location: " . $ShopPathSSL . '/' . $location);
exit;
}Code: Select all
/*
* FIX: This code uses a regular expression to take into account
* missing www. subdomains and the appended port number if they exist.
*/
$host = $shop_url['host'].":443" == "www.".$host ? $shop_url['host'] : $host;
// Use Regex to check if this is valid despite ports or lack/inclusion of www.
$pattern = "/^(www\.)?(".$shop_url['host'].")+(:443)?$/i";
$test = preg_match($pattern, $host, $matches);
//DEBUG echo "Test: ".($test ? 'true' : 'false'); exit;
//if (is_array($shop_url) && $shop_url['host'] != $host) {
if (is_array($shop_url) && !$test) {
// redirect if not correct host
$location = GetLocation();
ob_end_clean();
header("Location: " . $ShopPathSSL . ':443/' . $location);
exit;
}If anyone can point to where the Apache config may be out of whack and provide a more permanent fix for the host provider that'd be appreciated... I'd like to know what could cause such a scenario for curiosity sake if nothing else.