Zen Cart 1.5.5f
Database Patch Level: 1.5.5
Database: MySQL 5.6.41-84.1
PHP Version: 5.6.37 (Zend: 2.6.0)
The Shipping Estimator stopped showing actual estimates. I have UPS enabled and has been working this whole time.
Nothing on Error log.
Printable View
Zen Cart 1.5.5f
Database Patch Level: 1.5.5
Database: MySQL 5.6.41-84.1
PHP Version: 5.6.37 (Zend: 2.6.0)
The Shipping Estimator stopped showing actual estimates. I have UPS enabled and has been working this whole time.
Nothing on Error log.
"known" issue, need to modify the method of communication from the software to UPS to include possibly https:, ssl: and port 443, or other corrections. There is a thread here I believe something like UPS shipping estimates stopped January (don't recall the date but it was in the last 7 days). The change is done in the includes/modules/shipping/ups.php module. possibly look for ups.com and update as appropriate.
That would be this post: https://www.zen-cart.com/showthread....January-5-2019
Thank you for the swift reply!
I made the changes to old UPS module -> No luck
Updated the UPS module to newest -> No luck
Free Shipping or Store pick up options always seem to show up properly. Tried a trial FedEX module and it wouldn't show up either.
May be I need to update 1.5.5f to 1.5.6a?
Thanks, yes that was it.
If the module was updated, it may still need to have the change described above applied after that update. While for other reasons should update to 1.5.6a, it is not expected to be the source of this issue.
The new ups.php file in modules was significantly different from the old one. The new one did not have any references to ports. It has:
Above is the only reference to 'https' and no references to any ports.Code:if (!isset($this->_upsActionCode)) $this->_upsActionCode = '4';
$host = 'https://www.ups.com/using/services/rave/qcostcgi.cgi?';
$request = implode('&', array('accept_UPS_license_agreement=yes',
'10_action=' . $this->_upsActionCode,
'13_product=' . $this->_upsProductCode,
'14_origCountry=' . $this->_upsOriginCountryCode,
'15_origPostal=' . $this->_upsOriginPostalCode,
'19_destPostal=' . $this->_upsDestPostalCode,
'22_destCountry=' . $this->_upsDestCountryCode,
'23_weight=' . $this->_upsPackageWeight,
'47_rate_chart=' . $this->_upsRateCode,
'48_container=' . $this->_upsContainerCode,
'49_residential=' . $this->_upsResComCode));
$url = $host . $request;
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_VERBOSE, 0);
curl_setopt($ch, CURLOPT_HEADER, false);
curl_setopt($ch, CURLOPT_USERAGENT, 'Zen Cart quote inquiry');
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$response = curl_exec($ch);
$error = curl_error($ch);
This module update came out two days ago, Jan 8th.
Would suggest clearing your cache and cookie (or trying the process using a different browser so that a new session might be started.)
Good to know about the update including the change. I wasn't aware.
this module is now using curl. and my guess is you have a curl error.
when using curl with UPS and/or Fedex i like to log everything. that way if there is a problem you can see the last transaction in the log. i would modify your code as such:
we have now established a var called $ups_log that should have the last transaction for every curl call made in your code. it resides in your logs directory.PHP Code:
if (!isset($this->_upsActionCode)) $this->_upsActionCode = '4';
$ups_log = fopen(DIR_FS_LOGS . '/ups_error.log', 'w');
$host = 'https://www.ups.com/using/services/rave/qcostcgi.cgi?';
$request = implode('&', array('accept_UPS_license_agreement=yes',
'10_action=' . $this->_upsActionCode,
'13_product=' . $this->_upsProductCode,
'14_origCountry=' . $this->_upsOriginCountryCode,
'15_origPostal=' . $this->_upsOriginPostalCode,
'19_destPostal=' . $this->_upsDestPostalCode,
'22_destCountry=' . $this->_upsDestCountryCode,
'23_weight=' . $this->_upsPackageWeight,
'47_rate_chart=' . $this->_upsRateCode,
'48_container=' . $this->_upsContainerCode,
'49_residential=' . $this->_upsResComCode));
$url = $host . $request;
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_VERBOSE, true);
curl_setopt($ch, CURLOPT_HEADER, false);
curl_setopt($ch, CURLOPT_USERAGENT, 'Zen Cart quote inquiry');
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_STDERR, $ups_log);
$response = curl_exec($ch);
$error = curl_error($ch);
we have upped the logging to verbose, so that we can see everything. and we are sending the standard output for the curl call to the $ups_log.
i have not looked at this code before, so i'm not sure what it does with the $error; i can only assume something, that should point us to any potential errors with this call.
but in my experience debugging common carrier curl calls, this is the easiest way to figure out what is going on. and the beauty is that only the last transaction is stored..... we could change that but this is sufficient for my debugging.
you can try a transaction and post the contents of the ups_error.log. if it has any 'sensitive' information, i would modify it accordingly.
good luck.
while the symptoms may be the same (no estimates and no logs), that does not mean the problem is the same.
creating a curl transaction; sending it to an outside server; and then parsing the results can be fraught with errors.
i can not provide any info on the old plug-in module; i can only help if you want to go forward with your current situation. which you think is the curl transaction as that is the code you posted.
best.
Understood. I will be testing what's on your previous post now.
I got this from ups_error.log
Code:* About to connect() to www.ups.com port 443 (#0)
* Trying 23.43.242.135... * connected
* Connected to www.ups.com (23.43.242.135) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
* subject: CN=www.ups.com,OU=Unified Communications,OU=Hosted by United Parcel Service,OU=886234 - J2EE,O=United Parcel Service,STREET=340 MacArthur Blvd.,L=Mahwah,ST=NJ,postalCode=07430,C=US
* start date: Apr 24 00:00:00 2018 GMT
* expire date: Apr 23 23:59:59 2020 GMT
* common name: www.ups.com
* issuer: CN=COMODO RSA Organization Validation Secure Server CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB
> GET /using/services/rave/qcostcgi.cgi?accept_UPS_license_agreement=yes&10_action=4&13_product=GNDRES&14_origCountry=US&15_origPostal=33455&19_destPostal=34997&22_destCountry=US&23_weight=3.9&47_rate_chart=Customer+Counter&48_container=00&49_residential=1 HTTP/1.1
User-Agent: Zen Cart quote inquiry
Host: www.ups.com
Accept: */*
< HTTP/1.1 403 Forbidden
< Server: AkamaiGHost
< Mime-Version: 1.0
< Content-Type: text/html
< Content-Length: 314
< Expires: Fri, 11 Jan 2019 17:06:16 GMT
< Date: Fri, 11 Jan 2019 17:06:16 GMT
< Connection: close
< Server-Timing: cdn-cache; desc=HIT
< Server-Timing: edge; dur=0
<
* Closing connection #0
pretty cool, eh?
as you can see in the response, you are getting a 403 forbidden. so you are indeed having a problem with your curl request.
have you checked your server using ssllabs? put your website name here:
https://www.ssllabs.com/ssltest/
and let's see what sort of ssl problems you might be having.
i have a feeling you might be using the wrong tls encryption. but i could be wrong.... see:
https://www.ups.com/us/en/help-cente...-security.page
this file also gives you something that you can talk to the ups technical support people to see why you are getting the 403 forbidden.
hope that gives you a few places to start.
let us know what you find out.
Attachment 18260
That's what I got from https://www.ssllabs.com/ssltest/
what about this part:
Attachment 18261
Attachment 18262
Oops..
- you should talk to your host about disabling tls 1.0. see: https://www.globalsign.com/en/blog/d...-ssl-versions/
- you should read the notes on the downloads page for this module: UPS United Parcel Service - Version: 2015-12-30
This update only contains technical changes:
- switched to use CURL instead of the aging http_client for communications, as http_client is being retired
- self-check for future plugin updates
(explains your comment from above)- you can also look at the code to see how to get responses:
Code:// BOF: UPS
/*
TEST by checking out in the catalog; try a variety of shipping destinations to be sure
your customers will be properly served. If you are not getting any quotes, try enabling
more alternatives in admin. Make sure your store's postal code is set in Admin ->
Configuration -> Shipping/Packaging, since you won't get any quotes unless there is
a origin that UPS recognizes.
If you STILL don't get any quotes, here is a way to find out exactly what UPS is sending
back in response to rate quote request, you can uncomment the following mail() line and
then check your email after visiting the shipping page in checkout ...
*/
//mail(STORE_OWNER_EMAIL_ADDRESS, 'UPS response', $body, 'From: <'.STORE_OWNER_EMAIL_ADDRESS.'>');
// EOF: UPS
- i would contact UPS technical support to see why you are getting a forbidden response.
best.
Looks like UPS, FEDEX, USPS...all those modules do not work. My hosting is HostMonster.
I found UPS module working yesterday. Today, it doesn't seem to work again. Still have to contact Host Monster.
UPS Module Seems to be updated few days ago. Update notes go:
After updating, I still am not getting shipping estimates :dontgetitCode:Updated for improved compatibility with PHP 7.2
After communicating with my hosting, I got this reply, which I think was very insightful:
Quote:
Upon review of your Zen Cart thread as well as your site, it appears that there might be a problem with how UPS is interpreting your SSL certificate. When we went to visit your site, we noticed that it was pulling up as http as opposed to https. Since the site was not forcing the use of https on port 80, we believe that UPS was accessing your site with a different port and not seeing that there is an encryption layer.
We went through and forced the use of https on your site so that all traffic is connecting via port 80. Since your SSL certificate is not calling on the use of TLS v1, your site is not using this TLS version so UPS shouldn't be able to connect this way at all. Though it is still enabled on your server itself, it is not a default and would have to be hard coded in to call upon this TLS version.
While I'm not exactly impressed by the response, I would say that if the site has been forced to be all https by any arrival path, then the includes/configure.php and admin/includes/configure.php files should be updated to reflect the full site as https:. This is covered in this FAQ: https://www.zen-cart.com/content.php...alled-zen-cart
It entails modifying the constant HTTP_SERVER so that it begins with https: and to also ensure that any constant such as SSL_ENABLE has true between the single quotes such as:
Note that the includes/configure.php may have its permissions set to 0444 which would prevent saving the change(s). It may not fix this issue, but it is something that needs to be done for the way the site is currently set up.Code:define('SSL_ENABLE', 'true');
Currently, my includes/configure.php
I should make the HTTP_SERVER to be 'https'? So it would be as this:Code:define('HTTP_SERVER', 'http://www.*********.com');
define('HTTPS_SERVER', 'https://www.*********.com');
define('ENABLE_SSL', 'true');
Code:define('HTTP_SERVER', 'https://www.*********.com');
define('HTTPS_SERVER', 'https://www.*********.com');
define('ENABLE_SSL', 'true');
Go to admin->version and post your cURL version (the text next to it says "cURL information"). I have seen sites get into trouble because of old cURL versions.
That's your problem. This is a 10 year old version that's no longer secure (it uses an old version of OpenSSL).
The trouble is, you won't be able to convince your hoster of this. You'll need to go to a new hoster that stays more up to date (or move to a VPS account where you can update your own software).
What version should the cURL be?
7.63.0 is current
https://curl.haxx.se/docs/releases.html
Your version is 10 years old. Lots of vulnerabilities.
After communicating with my hosting, you were right, it was bad news in the sense that they cannot update cURL at the moment.
Do I have ANY OTHER options here, rather than a hosting change?
Nope. You need an updated cURL; UPS is getting more strict.
Changed the hosting plan to a server with cURL 7.62.0. Things seem to work for now :)
Thanks for confirming that this solved your problem.
DO want to thank you for all the help! :bow: