Jump to content

John W

♥Ambassador
  • Content count

    963
  • Joined

  • Last visited

  • Days Won

    18

Posts posted by John W


  1. While my code snippet was blocking all the attempts, I noticed there were increasing in the amount of attempts.  I started recording the ip addresses after noticing many started with 188.138.  However, after blocking 188.138.188.0/24 in my firewall, there has only been one in a few days.  In checking an abused ip db, that block shows up a lot. 


  2. Actually, I get his point.  When I was figuring out what to use to deny these guys, I thought about the country.  I only have 3 countries in my list, and the last one is Jamaica, but I very rarely sell to there.  Every one of the fake accounts was using Jamaica.  They put Google for company and google for tax id, so I picked the tax Id. 


  3. This came up in the 1980's mainly with gas stations as I remember.  In the end, it was ruled they could discount cash sales, but not surcharge in any way someone using a credit card.  I beleive there is a law in the US about it.  Maybe the FTC did it.


  4. I see Jack's point and it's one of the reasons I use the $company_tax_id, which I already had as part of SPPC addon.  I haven't had any spammers use apple or At&T, but I do have legimate customers in my database using both of those.  Apple as part of part of a business name and not Apple the company.  However, none of them have that as their $company_tax_id, so I would feel safe using it there.  I don't know if it's worth adding that field to do this, but since it already exist, I'm using it.  Every spammer account that I know of is using Google for company and google for tax id.

     


  5. When I use the test server, I use it in live mode.  It acts like the normal secure2 server, but in the sandbox.  I get a confirmation email and daily report just like secure sever. 

    Someone said they had a problem with ssl also.  The secure sever is supposed be https://secure2.authorize.net/gateway/transact.dll  It has a 2 after secure and there are 3 instances.  A.net switched to the Akamai routing network a few years ago and the link was changed.  I don't know if they will keep the old active as they bounced back and forth on that. 


  6. You can go search through the A.net info, but here's a piece of their info on md5.

    " Note that the MD5 Hash option exists for transaction responses sent by means of the Advanced Integration Method (AIM) or the Card Present (CP) implementation methods. However, these methods use Secure Sockets Layer (SSL) to ensure that the transaction response is legitimate, and so it is not as useful for AIM or CP merchants. "

    That comes from this link, but you can find several on their developer site.

    https://support.authorize.net/s/article/What-is-the-MD5-Hash-Security-feature-and-how-does-it-work


  7. If they are using Google for the company name, then you can add the code I posted early in this thread and change company_tax_id to company and it will block all of those.  I get a couple a day sometimes, but they are blocked.


  8. On my test site using my AIM module on their test server/sandbox it works with all the MD5 code commented out of the aim module.  I never had anything entered for it and all the md5 code was contingent on something being entered.  I think the md5 code was carry over from when Harald did the SIM module, but I'm guessing.

    I also downloaded their SDK for the api and have played with that a little on my test site with Netbeans.  Netbeans is helpful because it parses the code and can take you right to a class or method without having to hunt for it.  Since they have about 500 files in this api, NB is really helpful.  I used their sample code to get it to work from my test site.  I think we could reuse a lot of the aim module code and convert it to use the api. 


  9. People might want to read this post below on the a.net support forum.   From what i remembed the md5 is only needed for SIm.  I've been searching through all the developer info and working on the forums.  It's been a long time since I poked around here.

    Check this link

    https://support.authorize.net/s/article/Do-I-need-to-upgrade-my-transaction-fingerprint-from-HMAC-MD5-to-HMAC-SHA512-and-how

     


  10. I don't know if anyone will have interest in this, so I won't spend a lot of time on this unless it gains traction.  Anyway, I use batch print from over a decade ago and didn't realize until yesterday that the pdf class was still being maintained.  Since I only sell in the US, I haven't run into many character encoding problems, but I imagine some of you do.  So, the new version of Cezpdf seems to work with all the characters.  It's also php 7.2 compliant.  Even better, I was able to replace my old Cezpdf and Cpdf class files and associated files.  With very little changes, it prints my invoice.  The pdf manual seems pretty useful, but I haven't gone very far into it yet.  The main snag I hit was using "addTextWrap", which requires a different order than before.  But, it has more functionality, so I can right justify for totals, which I couldn't do before.  addText also has changed.  I only have a few hours into it, but check the manual out.

    So, I said wouldn't ramble too much.  If anyone is intersted you can find it at https://github.com/rospdf/pdf-php


  11. I think you're on to it.  I went to 7.1.25 and it didn't work on either.  Went back down to 7.0.33 and neither worked again.  Restarted my browser and 2.93 works now.  My head was starting to hurt.

    Unfortunately, I have to go cut the grass.  Fortunately, it's 77 degrees outside, so that's not too bad. 


  12. I am using an older version of 7.0 on my test site, so I'll upgrade that and see if it changes.  I doubt that's it, but maybe another setting I have.  I have Apache, php, and mysql all separately installed.  The AM_USE_TEMPLATES was set to true, but I have changed it to false and it still works.  The only  setting to true is

            $this->add('AM_USE_QT_PRO', true);

    But, I tried changing it to false and prices still update correctly.

    All the settings were the same on 2.9.4.  I figured it had something to do with "Product Attribute Code".

    Let me see if have time to update my php version of 7.0


  13. I should have mentioned, I'm using 7.0 right now on my test site where this problem showed up.  2.9.3 is working fine on my test site running 7.0.  

    I'm a little behind on getting some updgrades done.  My live site is using 5.6, so I'm preparing to move it to 7.0, then onward.  December is a good month for me to work on this. I've been a little burned out on this for a while.  Have some mods in my Admin I've been putting off dealing with, thus sticking with 5.6.

×