Jump to content

phi148

Members
  • Content count

    264
  • Joined

  • Last visited

  • Days Won

    2

phi148 last won the day on January 25 2019

phi148 had the most liked content!

About phi148

  • Birthday 01/01/2006

Profile Information

Recent Profile Visitors

13,351 profile views
  1. phi148

    AIM and SIM have reached End of Life

    I also use this and I am willing to help as well.
  2. phi148

    MySQL 8.0 - Anyone tried yet?

    Guess I'd be the first! I guess I'll hold on this for awhile. Seems like unknown territory.
  3. I'm currently running 5.7 and I'd like to upgrade to 8.0. Anyone else done this yet?
  4. phi148

    Google reCAPTCHA v3

    Don't you have to edit contact_us.php and create_account.php as well to make the call to initReCaptcha ? For example, in "contact_us.php" don't you have to have this command somewhere? echo $OSCOM_Hooks->call('contact_us', 'initReCaptcha');
  5. I think I fixed it. Downloaded this new file http://curl.haxx.se/ca/cacert.pem And replaced it here: /home/xxxx/public_html/ext/modules/payment/authorizenet/authorize.net.crt I *think* this is the answer. Will keep you all posted if it fails again.
  6. I was able to capture some output: * Trying 198.241.207.102:443... * TCP_NODELAY set * Connected to secure.authorize.net (198.241.207.102) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /home/xxxx/public_html/ext/modules/payment/authorizenet/authorize.net.crt CApath: none * SSL certificate problem: self signed certificate in certificate chain * Closing connection 0 Notice the error --> * SSL certificate problem: self signed certificate in certificate chain
  7. All, today an update was rolled out with authorize.net They call it Phase 4b. You can see it here: https://support.authorize.net/s/article/Authorize-Net-Network-Change-FAQ Ever since this happened, I noticed something very odd. Intermittently I couldn't connect to authorize.net. I narrowed it down to the IP address 198.241.207.102 Interestingly enough, the other IP that they use (198.241.206.93) works fine. These 2 IP addresses seem to change at random times. You can see these are the IPs that are allocated to: secure.authorize.net/gateway/transact.dll as shown here: https://support.authorize.net/s/article/Authorize-Net-Domains-and-IP-Addresses So essentially, depending on which IP that the endpoint resolves to, either a payment goes through or it doesn't. I think this must be a problem that has to do with me having an outdated certificate (This is my guess) Does anyone else have this problem AND does anybody have an updated certificate that goes here /public_html/ext/modules/payment/authorizenet/authorize.net.crt I was able to temporarily get around this problem by setting Verify SSL Certificate to False in my authorize.net settings in oscommerce. Thank you,
  8. phi148

    AIM and SIM have reached End of Life

    I fixed it by adding this code to create a customer profile which now lets me save the customers information so I can rebill them easily. I just added this as a last minute feature after a successful credit card transaction. Seems to work just fine for me. I also have it send me an email if it fails for some reason. That part has not been tested yet since it seems to be working and not executing that code. if ($error == false) { $g_loginname = substr(MODULE_PAYMENT_AUTHORIZENET_CC_AIM_LOGIN_ID, 0, 20); $g_transactionkey = substr(MODULE_PAYMENT_AUTHORIZENET_CC_AIM_TRANSACTION_KEY, 0, 16); $posturl = "https://api.authorize.net/xml/v1/request.api"; $content = "<?xml version=\"1.0\" encoding=\"utf-8\"?>" . "<createCustomerProfileFromTransactionRequest xmlns=\"AnetApi/xml/v1/schema/AnetApiSchema.xsd\">" . "<merchantAuthentication>" . "<name>" . $g_loginname . "</name>". "<transactionKey>" . $g_transactionkey . "</transactionKey>" . "</merchantAuthentication>" . "<transId>" . $response['x_trans_id'] . "</transId>" . "</createCustomerProfileFromTransactionRequest>"; $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $posturl); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_HTTPHEADER, Array("Content-Type: text/xml")); curl_setopt($ch, CURLOPT_HEADER, false); curl_setopt($ch, CURLOPT_POSTFIELDS, $content); curl_setopt($ch, CURLOPT_POST, true); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); $response_cim = curl_exec($ch); curl_close($ch); $parsedresponse = @simplexml_load_string($response_cim, "SimpleXMLElement", LIBXML_NOWARNING); if ($parsedresponse->messages->resultCode == "Error") { $to_name = STORE_OWNER; $to_email_address = STORE_OWNER_EMAIL_ADDRESS; $email_subject = '!!! Customer Information Manager Alert !!!'; $email_text = '<span style="color:red;">Customers information was not stored in authorize.net</span>'; $from_email_name = 'Authorize.net ALERT Notification'; $from_email_address = STORE_OWNER_EMAIL_ADDRESS; tep_mail($to_name, $to_email_address, $email_subject, $email_text, $from_email_name, $from_email_address); } }
  9. phi148

    AIM and SIM have reached End of Life

    I need to find out for sure. You may be right. Assuming you are correct, then it looks like I need to implement Authorize.net "CIM". Which doesn't exist either right now
  10. phi148

    AIM and SIM have reached End of Life

    Hey all. I’m currently using AIM. However the “rebill” function is going away and AIM is also end of life. Having to call customers to get their payment info over and over will really become a pain and I was hoping to avoid that.
  11. I'm in need of this too. Looks like I may have to switch payment processors if the community no longer wants to support authorize.net
  12. phi148

    AIM and SIM have reached End of Life

    Really need this to be updated! Anybody working this by chance?
  13. phi148

    Multi_Vendor_Shipping new thread

    I don't believe this has been done yet, but I also would be interested in this... if and when I upgrade to Phoenix.
  14. Hi John, Yes, SSL does provide security - but only between the client and the server. It does not ensure the data itself traversing the SSL is accurate. Hashing, encryption, etc.. protects the data itself from breaches and verifies the validity of said data. Is it overkill? Probably... and again personal preference. In my opinion, if the option to further validate my data is there, I'll take it. Notice they say "not as useful for AIM or CP merchants". If it was completely "not useful" then I imagine it would of been abandoned entirely.
  15. I use the MD5 code and I highly suggest everybody else use the new method with the sha512 hash. From a security perspective it is critical. Is security optional? Yes. However, why wouldn’t you take the extra five minutes to implement this for you and your customers security?
×