Jump to content

TomB01

Members
  • Content count

    189
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by TomB01

  1. I've been getting the infamous "This module supports only xpci version 1.0001 of the UPS Rates Interface." error message lately. I'm running 2.3.4 and had UPSXML 1.4.0 installed, so updated to 1.6.1. That didn't fix it. After some searching on the Internet, all I found were some very dated references stating that the UPS servers had gone offline. Their problems seemed to get fixed on their own, apparently when the UPS servers went back up. Mine seemed to be lasting longer than any sort of server issue, so I created the logging file as specified in UPSXML. This is what I get as a response from UPS in the log file: So, I filed a trouble request at UPS. This is their response: Is UPSXML dead? Is there another module I can use? Luckily, I have USPS and FedEx working just fine, but I had the option for UPS if a customer chose to use it - but not anymore. Help?
  2. TomB01

    Stripe Upgrade to TLS 1.2

    I've been using the Stripe.js 1.1 payment module since I loaded OScommerce 2.3.4 several years ago. It's worked without a hitch since then. However, I received an e-mail a couple of weeks ago from Stripe. It said my OScommerce store has been making Stripe requests using TLS 1.0. Further, Stripe says they will disable all requests using TLS 1.0 as of June 13, 2018. My ham-handed effort at testing the stripe.php file and using the Stripe test API keys, also results in this: This is identical to a problem I discovered recently with my UPS XML 1.6.1 shipping module. We solved that and it works great - link here: Since my UPS shipping now works, that means my hosting service has all the proper tools to use the later TLS 1.2. However, I cannot find similar code in the stripe.php. I found the section using curl, and tried to add this line that we added in the UPS module: curl_setopt($ch, CURLOPT_SSLVERSION, 6); That failed. Anyone know how I can make my Stripe module use TLS higher than 1.0?
  3. TomB01

    Updated Stripe payment module

    OK - at least with my hosting service (HostGator), it seems all I had to do was upgrade to PHP 5.4. That fixed everything.
  4. TomB01

    Stripe Upgrade to TLS 1.2

    OK - it's all fixed and I even went back to the original UPSXML v1.61 file. It seems that all I had to do was upgrade my PHP to 5.4 on my server.
  5. TomB01

    Stripe Upgrade to TLS 1.2

    I'm sorry, but the very reason I mentioned the UPSXML is because adding the curl statement you suggest worked for the UPSXML issue. I referenced "curl_setopt($curl, CURLOPT_SSLVERSION, 6);" in my original post that created this thread. (UPSXML used $ch instead of $curl.) Trying that statement in stripe.php however, did not work. Why would it work for UPSXML, but not stripe? Note that in UPSXML I also had to specify $this->use_exec = '1'; but this statement doesn't exist in stripe.php. I just tried it again using "curl_setopt($curl, CURLOPT_SSLVERSION, 6);" It failed. My hosting service is HostGator. I have spent hours with them before on the TLS issue regarding UPSXML and it took this forum to finally come up with a solution. I'm hoping that you will find what's wrong here.
  6. TomB01

    Updated Stripe payment module

    Maybe I should've posted my issue here. Stripe is telling me that unless I start using TLS later than 1.0, my store's requests will not go through as of June 13, 2018. I am using the Harald Ponce de Leon module v.1.1. Experience with a similar issue for UPS XML shipping tells me the issue is in the stripe.php file. That's how we were able to upgrade the calls to TLS 1.2 with the UPS shipping module (upsxml.php). I can't find similar code in the stripe.php file, however. I'm pretty sure it has to do with the curl calls, but like you said, it's way above my pay grade.
  7. Yeah, I forgot the new URL was imbedded in the middle of that description up there. That's what probably broke it in the first place, but I had installed the new version of UPSXML in the interim and then developed the security issue.
  8. That error happened spontaneously. I only discovered it recently when using a test account to my store. (My store has operated for many years.) I had just experienced a recent change with USPS that broke my 1st Class Shipping (1st Class Parcel to 1st Class Package - Retail). In fixing that, I noticed that the UPS Shipping was broken, too - with that error message. My first reaction was to upgrade to the latest UPS XML as mentioned in the first post up there. That didn't fix it and resulted in the numerous posts above, until Valeriy's post up there fixed it - changing the "0" to "1" in the code of upsxml.php. That line that Valeriy references is somewhere in the middle of that file, but fairly easy to locate: $this->use_exec = '0'; The latest UPSXML contrib has the "0" as default. Anyway, changing that "0" to "1" fixed it for me. Numerous trouble chats with both UPS and my HostGator services accomplished nothing.
  9. I'll be danged - that worked! Many thanks, Valeriy! It's unbelievable how much difference it made changing a '0' to '1' on that line.
  10. There is something else going on. HostGator has proven to me that TLS 1.2 is working on my server. Yet, UPS still gives that as the reason for the cURL error 35. Ideas, anyone?
  11. HostGator says there's nothing wrong with their web services (cURL version) or my site and that the issue is with UPS. I've sent another e-mail to UPS.
  12. Still doesn't work. I even tried removing and re-installing the module. I also tried both "onlinetools.ups.com" and "www.onlinetools.com." However, the logging file error message has changed with "onlinetools.ups.com" - it now says, The e-mail from UPS had a reference to TLS V1.2. I found a reference here from Harald Ponce de Leon that said cURL implemented TLS V1.2 with cURL V7.34. My server info from the OSCommerce Admin says the cURL is V7.24. I've contacted my hosting service.
  13. OK - thanks. I will give it a shot and report back.
  14. OK, so does that mean if I go in and change all references for "www.ups.com" to "onlinetools.ups.com" it will work? The e-mail from UPS stated, "www.onlinetools.com"
  15. Outstanding! Both the UK test address and my customer's address from the Netherlands now works with no errors! Many thanks, Jim!
  16. Upgraded to V2_r3.6 Same error, with a slight change in line numbers (line number 123 changed to line number 124): The error message above is at the top of a blank screen after clicking "Continue" from the checkout page. It also generates this on the checkout at the top of the page, but displays the rest of the page with all shipping options and pricing correctly: Here's the usps.php file with lines of code before and after as requested: Again, this is an intermittent issue, depending on the country address. I have test addresses for Taiwan, Canada, and Australia - no problem. Then the one from the Netherlands fails and so does one from the UK.
  17. Thanks for all of your effort in keeping this up-to-date, Jim. I will upload the new version as soon as I can and report back.
  18. Got another one: This is failing for a customer address in the Netherlands: Warning: Invalid argument supplied for foreach() in /home1/xxxx/public_html/catalog/includes/modules/shipping/usps.php on line 123 Warning: Cannot modify header information - headers already sent by (output started at /home1/xxxx/public_html/catalog/includes/modules/shipping/usps.php:123) in /home1/xxxx/public_html/catalog/includes/functions/general.php on line 49 Attempts on usps.com seem to work with the customer's address. Also, test addresses from Australia, Taiwan, etc., have no issue.
  19. I seem to be getting a specific error with any address from Denmark: Everything seems fine otherwise. I have tried addresses for Australia, Taiwan, UK, Canada, etc. and everything works just fine. However, I get the message above on the shipping page in checkout with whatever I put in for Denmark, apparently. Proceeding further in checkout bombs out completely with the following: Is there some error with the database in using Denmark? P.S. I have UPS and FedEx shipping options running at the same time, too - with no errors. P.P.S. This seems to be locking up on the usps.com website as well. It will "Calculate a Price" OK, but then if you select, "Print Postage" it locks up completely and comes back with a "Session Timeout" message.
  20. TomB01

    [Addon} Modular Front Page

    I guess it was some sort of error in the HTML I used. I wiped out the added text in PHPAdmin and carefully added new text with correct HTML (don't know what I did the first time). Now, everything is fine.
  21. TomB01

    [Addon} Modular Front Page

    I just entered some new text to Text Main this morning. Now, I can't edit the text anymore. When I select Edit, I no longer get the text field to edit anymore. At the top of the Modules listing in Admin, this is the error message: "Parse error: syntax error, unexpected T_STRING in /home1/tomb/public_html/catalog/tube4391/modules.php(251) : eval()'d code on line 3" ​
  22. TomB01

    Stripe vs Braintree?

    I'm building a replacement web store based on 2.3.4 (not going to try the upgrade route from 2.2). All of the extra capability over 2.2 is exciting, but it's confusing, too. I've been using simple Paypal for the last 7 years with great success, but would love to start taking credit cards. Both Stripe and Braintree have what I'd like: simple fees per transaction only, no monthly charges or other extras, and credit card acceptance totally contained on my store site - no switching to another site and back again. So, what are the advantages/disadvantages of either one? Is there another one out there that's better given the preferences above? I have noticed that Braintree is already inserting random adds on my regular web surfing, so I'm not sure I like an outfit that appears to be that aggressive with marketing. I only visited their site once!?
  23. TomB01

    New UPS XML Shipping Module available

    Geez guys - thanks, much, but that was my problem 3 weeks ago and post #2389 up there fixed it. No offense, but what about the issue that popped up today? Do I need to worry about UPS telling me that I still have "test" access for parts of the API that don't appear to be used?
  24. TomB01

    New UPS XML Shipping Module available

    OK, I received this "Tech Alert" today from UPS: Looking at my Access Key Confirmation on UPS, it shows that I still have "Test" access for the following: I don't ever have local pickup, but all of this is leading me to enter values for "Pickup Confirmation," "Bill Of Lading Number," and "Rate Value." I don't have a clue for any of those. Is any of this a concern? Should I make up some values to put in those fields so that I can get Production API access for these features or what? EDIT: Sorry about this formatting, IE is really squirrelly using this forum.
×