Australia Post Delivery Rate Server Down

[Geronimo]

Mmmm, well wish me luck then - I'm about to phone them. :)

Thanks Rod.

Regards

Philip

[Geronimo]

Hi Rod

I've just got off the phone from GoDaddy. They pointed me to a section of their help system which seems to address our situation. It give some php code to ensure that any scripts go through their secure proxy server.

I know I've got Zen Cart set up to use the appropriate protocal - proxy.shr.secureserver.net:3128 - set via Configuration->My Store, but I wonder if a variation of this particular piece of code needs to be incorporated in the austpost module to be effective.

The help screen is at http://help.godaddy.com/article/289 It is set to give access to the paypal server so I figure (with the appropriate austpost URL substituted for the paypal one) it may work for me.

The problem, of course, is that I have no idea where it should go in my system. So my questions are:

Am I headed down the right track, and can you tell me where to put it - in a manner of speaking?!

Thanks yet again....

Kind regards

Philip

[Geronimo]

It would help if I gave you the code wouldn't it? :)

From the help screen:

Note: On our shared hosting, any CURL applications that make secure HTTP connections (HTTPS over port 443) need to pass through a proxy server. The address for this proxy server is proxy.shr.secureserver.net and connections must specify the use of port 3128. The code below already includes this information.

<?

$URL="https://www.paypal.com";
if (isset($_GET["site"])) { $URL = $_GET["site"]; }
$ch = curl_init();
echo "URL = $URL <br>n";
curl_setopt($ch, CURLOPT_VERBOSE, 1);
curl_setopt ($ch, CURLOPT_HTTPPROXYTUNNEL, TRUE);
curl_setopt ($ch, CURLOPT_PROXYTYPE, CURLPROXY_HTTP);
curl_setopt ($ch, CURLOPT_PROXY,"http://proxy.shr.secureserver.net:3128");
curl_setopt ($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
curl_setopt ($ch, CURLOPT_URL, $URL);
curl_setopt ($ch, CURLOPT_TIMEOUT, 120);
$result = curl_exec ($ch);
echo "<hr><br>n";
echo 'Errors: ' . curl_errno($ch) . ' ' . curl_error($ch) . '<br><br>';
echo "<hr><br>n";
curl_close ($ch);
print "result - $result";
echo "<hr><br>n";

?>

[RodG]

It would help if I gave you the code wouldn't it? :)

From the help screen:

Note: On our shared hosting, any CURL applications that make secure HTTP connections (HTTPS over port 443) need to pass through a proxy server. The address for this proxy server is proxy.shr.secureserver.net and connections must specify the use of port 3128. The code below already includes this information.

<?

$URL="https://www.paypal.com";
if (isset($_GET["site"])) { $URL = $_GET["site"]; }
$ch = curl_init();
echo "URL = $URL <br>n";
curl_setopt($ch, CURLOPT_VERBOSE, 1);
curl_setopt ($ch, CURLOPT_HTTPPROXYTUNNEL, TRUE);
curl_setopt ($ch, CURLOPT_PROXYTYPE, CURLPROXY_HTTP);
curl_setopt ($ch, CURLOPT_PROXY,"http://proxy.shr.secureserver.net:3128");
curl_setopt ($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
curl_setopt ($ch, CURLOPT_URL, $URL);
curl_setopt ($ch, CURLOPT_TIMEOUT, 120);
$result = curl_exec ($ch);
echo "<hr><br>n";
echo 'Errors: ' . curl_errno($ch) . ' ' . curl_error($ch) . '<br><br>';
echo "<hr><br>n";
curl_close ($ch);
print "result - $result";
echo "<hr><br>n";

?>

This may work for PayPal (which uses https), but it won't work for the AP module because it uses regular http rather than https, so even if you did set up this way you will possibly get the external access, but they will be trying to connect to the wrong server port.

<10 mins later>

Just to prove a bit of a point, I have just reconfigured the austpost.vcsweb.com server so that it will accept https requests.

What you need to do is load the austpost.php script into a text editor, locate the line that reads
$SERVER = "http://austpost.vcsweb.com/" and change it to
$SERVER = "https://austpost.vcsweb.com/"
(this will be somewhere around line#123)

Save the file and try getting a quote on our test product.

All being well you should get a valid quote for the delivery methods that *don't* require a connection to the drc.edeliver server (in other words, the only quotes you'll see are the prepaid satchels).

Unfortunately, I have no control over the drc.edeliver servers so I can't do anything for you in that regard, so although not a 'cure' it should go to prove the point that we are now looking at a http vs https issue.
Godaddy *may* have another proxy or port number to handle the non https requests. (As per the details in the servers.txt file, the austpost.vcsweb server handles the 'fixed price' items, and everything else gets redirected to the drc server).

Cheers
Rod

[RodG]

The help screen is at http://help.godaddy.com/article/289 It is set to give access to the paypal server so I figure (with the appropriate austpost URL substituted for the paypal one) it may work for me.

The problem, of course, is that I have no idea where it should go in my system. So my questions are:

Am I headed down the right track, and can you tell me where to put it - in a manner of speaking?!

Philip

I probably should have responded to this one first. Yes, you are heading down the right track, but you don't need to put that godaddy supplied code anywhere. It is already incorporated into zen-cart and the AP module. The code isn't exactly the same, because the zencart code makes use of a few more variables, which is why zencart can have 'global' settings for the cURL proxy/port, rather than being hard coded into each of the modules that require them.

Having said that, if you take a look at the cURL related code in the austpost.php script (where you commented out that debug line) you will find that the code is very similar to what you found on godaddy.

Bottom line.... nothing for you to do in this regard, especially if you can get a quote on the prepaid satchels by making the http/https change as per previous message.

Cheers
Rod

[Geronimo]

Hi Rod.

Just got back home again. I've added the "s" to the http in the relevant line of the austpost.php file and checked again. I get a different error message this time:

ERROR: SSL certificate problem, verify that the CA cert is OK
via sessionoverideC 1000 - W 10.00 - H 2.5 - L 10.00 - I

The estimate I get for the prepaid satchels is still only what I've entered as P&H though...

I'm going to look on GoDaddy help to see if there is any proxy info for http requests.

Regards

Philip

[RodG]

Just got back home again. I've added the "s" to the http in the relevant line of the austpost.php file and checked again. I get a different error message this time:

ERROR: SSL certificate problem, verify that the CA cert is OK

I was a little bit afraid of something like that. That error is caused because we use a self-signed certificate.

It does prove that the https requests are actually working though (in order to get that error the proxy server must have made a connection to our server).

The estimate I get for the prepaid satchels is still only what I've entered as P&H though...

Unfortunately, that is because of the certificate problem (it is now connecting to our server, but the error is preventing the transfer of data).

It isn't exactly what I was hoping for (obviously), but it does prove the same point that I was hoping to prove, in that it really is an http/https issue.

I'm going to look on GoDaddy help to see if there is any proxy info for http requests.

Regards

Philip

I've already taken a look around and didn't find anything relevent, other than the fact that much of their text implies that they do support non SSL cURL (but don't give any details in regards to the proxy settings). It seems odd that they give details for the https but not the other.

This does make it easier for you to explain the situation to them though, 'cos all you have to do is get them to understand that https is fine, but http to the exact same server is being blocked, and you *require* non-SSL cURL support.

Cheers
Rod.

ps. Unless you want to keep the debugging information enabled for your own interest you can probably revert the austpost.php code back to the original. You won't need to change anything in this code for things to work for you once godaddy either fixes the problem or gives you more info on how to make non-SSL cURL work. (in which case the changes will be in the zencart/admin/config rather than anything to do with the AP module.

[Geronimo]

ps. Unless you want to keep the debugging information enabled for your own interest you can probably revert the austpost.php code back to the original. You won't need to change anything in this code for things to work for you once godaddy either fixes the problem or gives you more info on how to make non-SSL cURL work. (in which case the changes will be in the zencart/admin/config rather than anything to do with the AP module.

I found the same as you did, Rod, with GoDaddy. Nothing really to help. I'll contact them again and see if I can get details of NON SSL cURL, and will switch off the error reporting too.

In the meantime, I've set up a basic table rate system and named it Australia Post for the screen display. I've got it to use the AP logo you supplied - I hope that's OK. I'm keen to get some products listed and be able to point people to the site soon.

I'll post again if I have any luck with GoDaddy. It may help someone else with a similar problem.

Thanks HEAPS for what I consider to be an amazing effort in supporting me with my "issues". :) I sure appreciate your time and expertize.

Kind regards

Philip

[RodG]

I'll post again if I have any luck with GoDaddy. It may help someone else with a similar problem.

That's IF you have any luck. From comments made in the past by Dr.Byte I personally don't hold out too much hope, but who knows, they may be waiting for just one more person to report the problem before doing anything about it, and you may just be that one person

Thanks HEAPS for what I consider to be an amazing effort in supporting me with my "issues". :) I sure appreciate your time and expertize.
Kind regards

Philip

Oh, I forgot to ask. Where do I send my bill too? <big grin>

Seriously though, you have probably helped me as much as I've helped you. What with all the testing and checking that you have done (and I thank you for your patience during all this) you have given me some valuable insights and methods of improving my debugging techniques, and have even provided information that will aid in future debugging of similar problems, so any time and effort that I've spent is ultimately to my own benefit anyway.

My only regret being that although we've completely isolated the problem, it hasn't actually solved your problem.. at least not yet.

Cheers
Rod

[RodG]

Philip,
Would you care to do me a favour?

Load austpost.php into a text editor, find the cURL related code (near where you commented out that debug line).

Find the line that reads something like:
messageStack->add_session('cURL communication error'......)

Then immediatly after that line add:
echo $error ; exit ;

Please let me know what you see when you try ro get a quote (try both with https://austpost.vcsweb.com and again with just http://vcsweb.com.

It should give the same error message(s) that you were getting with that debug line uncommented. If it does, just leave the code in place, because I'll be incorperating similar in the next release, which should make it easier for me to identify this problem if others experience it.

Cheers
Rod