Jump to content


  • Content count

  • Joined

  • Last visited

Posts posted by Enzo79

  1. I too have been getting lots of problems with these spam/fake accounts being created and worse over the last few months, exactly the same as everyone else usually something like same name for first name and last name with two capital letters on the end e.g.  'samename samenameGP'

    Most of it seems to go back to IP's from Moldova and the Russian Federation, tried to block some IP address ranges and it did cut it down, but its a never ending battle, I did also try and block those countries in my .htaccess but either they get round it or my host doesn't let me do it that way.

    I found that if I get these fake accounts I get loads more spam email than normal, and if block the fake accounts from registering I don't get any spam, its like they register using a genuine email address that works, and as soon as they get the welcome email they automatically fire back loads of spam at the address it came from.

    I found this thread in a way of trying to stop it, and I have just come up with another simple way that seems to have worked for me.

    I don't use the customers_fax field, I have even removed the part of the page that displays the input field on the create_account page, but all the fake accounts are still managing to put a entry in the DB for customers_fax, but none of the genuine customer registrations do.

    I just made a super crude error... so if the entry in customers_fax is longer than the minimum length that's used for the Telephone Number as set in admin it will throw an error, but didn't even bother putting a error message up.

        if (strlen($fax) > ENTRY_TELEPHONE_MIN_LENGTH) {
          $error = true;

    I did look at some other fields that I don't use, like customers_gender… but with all the other ones there seems to be some anomalies depending on how the customer registered, as people who manually fill the form end up with the customers_gender set to NULL, but for customers that have their details automatically completed by PayPal Express checkout have that field empty.

    Obviously wont work for everyone, but it kind of shows how crude these bots are, as have read loads of stuff before about people using .css to make a hidden input field transparent, or positioning them off the screen, but in reality there is no need.

  2. 6 hours ago, MrPhil said:

    Yeah, anything starting with # is commented out and can be ignored. If you uncomment them, you'll probably get a 500 error since they're obsolete.

    But I assume I can safely delete that section completely?


    6 hours ago, MrPhil said:

    You should add a test for domain name and combine the HTTPS test into the same rewrite, so there's only one 301 redirect happening.

    I will make the suggested changes to this section, thanks for your input.

  3. 11 hours ago, BrockleyJohn said:

    If you're worried about breaking the live system, set up a test copy of your store.

    If set up a test copy of the site, what's the best way to update?

    Do I just use the update thing in the app, or is there less risk of it going wrong if I uninstall the payment modules, do the updates and then re-install them?

  4. I too am having trouble with the TLS v1.2 Test... but have been using PayPal Pro Hosted for a couple of years and they haven't at any time contacted me or put any limit on my account, so am wondering if its just the test that doesn't work for me.

    PHP: 7.2.6
    PayPal App: v4.039
    Running on: BS
    cURL Version: 7.59.0
    cURL SSL Version: OpenSSL/1.0.2o 

    I have tried the newer version of the paypal.com.crt off of Gary Burtons GitHub, but that hasn't sorted it.

    App can retrieve balance, and all the bits in the log are green.  Does anything in the log tell me if its using TLS v1.2?

    The weird thing is I did accidentally break the Paypal app somehow a few days ago, and had to get my host to install a back up of the files and DB from 6 days ago to get it all working, but in that time I had tried to install various versions of the PayPal app but couldn't get any of them to work properly and load the iframe, but the TLS v1.2 test was passing using the newer versions of the app!

    Anyone got any pointers?  I am reluctant to update the app, as don't want to break it again.

  5. I have finally got it working... I really don't know what I had done, if I had done it, or if I just made things worse in the last few days trying to change to a newer version of the app...

    On comparing the old and new versions of the DB there were 18 rows from the Configuration table to do with PayPal that had gone missing.

    I started manually putting the missing ones back in one by one, and before I even completed it had an order come through!

    Thanks to everyone that has made some input, and I will make the changes to the .htaccess as advised.

  6. Just as quick update the host have used a backup of my files from midnight on the 6th, and am now back to the PayPal app v4.039, but its still not working.

    They have done me a backup of the DB from the same time, and set it up as a new DB, so I can compare the current and old one.

    Am I right in thinking the only bits in the DB that I could/would have messed up in the meantime are in the CONFIGURATION table?

  7. 4 hours ago, MrPhil said:

    Do you have any subdomains or add-on domains in play here?

    No, there are no subdomains or add-on domains.

    4 hours ago, MrPhil said:

    Do you have any php_value or php_flag entries left in your .htaccess? They belong in a php.ini file (or equivalent).

    The only php_value ones are the ones that I think are commented out.

    # Fix certain PHP values
    # (commented out by default to prevent errors occuring on certain
    # servers)
    # php_value session.use_trans_sid 0
    # php_value register_globals 1

    Infact I don't think there is anything in my entire .htaccess that I don't mind posting on here... if someone could have a look over it and see what bits I can ditch, and end up with something that could cause me as little problems as possible.

    <IfModule mime_module>
    AddType application/x-httpd-ea-php72 .php .php7 .phtml
    RewriteEngine On
    RewriteCond %{HTTPS} !on
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
    # $Id$
    # This is used with Apache WebServers
    # For this to work, you must include the parameter 'Options' to
    # the AllowOverride configuration
    # Example:
    # <Directory "/usr/local/apache/htdocs">
    #   AllowOverride Options
    # </Directory>
    # 'All' with also work. (This configuration is in the
    # apache/conf/httpd.conf file)
    # The following makes adjustments to the SSL protocol for Internet
    # Explorer browsers
    #<IfModule mod_setenvif.c>
    #  <IfDefine SSL>
    #    SetEnvIf User-Agent ".*MSIE.*" \
    #             nokeepalive ssl-unclean-shutdown \
    #             downgrade-1.0 force-response-1.0
    #  </IfDefine>
    # If Search Engine Friendly URLs do not work, try enabling the
    # following Apache configuration parameter
    # AcceptPathInfo On
    # Fix certain PHP values
    # (commented out by default to prevent errors occuring on certain
    # servers)
    # php_value session.use_trans_sid 0
    # php_value register_globals 1
    <IfModule mod_headers.c>
      Header unset ETag
    FileETag None
    ## https://gtmetrix.com/leverage-browser-caching.html ##
    <IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType image/jpg "access plus 1 year"
    ExpiresByType image/jpeg "access plus 1 year"
    ExpiresByType image/gif "access plus 1 year"
    ExpiresByType image/png "access plus 1 year"
    ExpiresByType text/css "access plus 1 month"
    ExpiresByType application/pdf "access plus 1 month"
    ExpiresByType text/x-javascript "access plus 1 month"
    ExpiresByType application/x-shockwave-flash "access plus 1 month"
    ExpiresByType image/x-icon "access plus 1 year"
    ExpiresByType application/javascript "access plus 1 year"
    ExpiresDefault "access plus 2 days"
    <Files 403.shtml>
    order allow,deny
    allow from all
    deny from
    deny from
    deny from
    deny from
    deny from
    deny from
    deny from
    deny from

    I don't really know what I am doing, and tend to learn as I go... but from what I can understand, the first bit lists all the versions of PHP I can run, so can try and roll it back to an earlier version of PHP7 until they remove it.   The next bit is the redirect to make sure everything is .https, but will switch that out for JCMagpie's version.

    Not sure what next bit is, and the bit after that is to do with caching, but I have never put that in, must have been done by the host.  I do have problems with some browsers not loading the newest versions of pages on my site, IE especially, so maybe that section needs a tweek.

    The last bit I assume is where I have blocked some URLs that were trying to do some weird stuff, like stuff added on the end of URL's, but when I googled the URL they were trying it keep coming up with wordpress vulnerabilities, but I don't use wordpress so guessed it was people just trying stuff incase you did.

  8. 1 hour ago, JcMagpie said:

    To force all of the web traffic (every link in your website) to use HTTPS insert the following lines of code in the .htaccess file:

    Whats the difference between the way the host told me to do it and the way you have recommended?

    RewriteEngine On
    RewriteCond %{HTTPS} !on
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}


    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]


  9. 1 hour ago, JcMagpie said:

    Speak to your host, most good hosts will have nightly or weekly backups you can restore from.

    I have spoken to host, and they have nightly backups at midnight and keep them for 6 days, so can roll me back to midnight on the 6th.

    I had an order at 22:11 on the 6th where the customer paid straight off a credit/debit card using the PayPal Pro Hosted which uses the iframe, so was definitely working then.

    Fingers crossed the backup works.

  10. 8 hours ago, ArtcoInc said:

    Do you have a full backup of your site (both files AND database) from before you made your 'security' changes?

    In a schoolboy error kind of way I don't have backups of either.

    The only change I made was adding the following code to the .htaccess file, as when visitors first came on the site the index.php page wasn't secure, and obviously now throws a warning in some browsers.

    RewriteEngine On
    RewriteCond %{HTTPS} !on
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

    My last edit to .htaccess file was on the 2nd September, so don't think this has anything to do with it either.

  11. 8 hours ago, ArtcoInc said:

    What version of PHP was your host using before the upgrade? Can you ask them to roll PHP back to a prior version?

    I spoke to them yesterday and they said it was on 7.1.2 they actually did the switch back on the 23rd of August, so as it was working fine until the 7th September I don't think this is my problem. 

  12. I don't know if its something I did, only changes made recently were so whole site was made secure, and a recent switch to PHP 7.2.6 by the hosting company, but over the weekend something seems to have gone wrong, and now have no end of PayPal related problems.

    Site runs on a BS version of 2.3.4 from about this time last year, and was using the PayPal app, using both the Express Checkout and Payments Pro Hosted parts with no problems.

    Since the weekend when you go through checkout and select the option for paying by card (PayPal Payments Pro Hosted) it used to open up in a iframe on the checkout_confirmation.php page, but for some reason nothing now shows up, and you are left with a checkout_confirmation.php page with the bottom bit missing.

    The Express Checkout thing will also sometimes be a bit sketchy, as I seem to be able to stuff in a weird order to get it to kind of work, but other times it will throw a 500 error, but not one that ends up in the error log, and have spoke to the hosting company and they have said its an Apache error and is just that the script timed out.

    Various bits in the app seem to work, it can fetch my PayPal Balance, and passes that TLS V1.2 test, but if I try and get it to automatically retrieve my API credentials I click on the button and it thinks about it for a while, and then throws that same '500 Internal Server Error'

    As an emergency I have switched to using PayPal Standard so I can take some sort of payment, and that pretty much works, as I can put through real test orders using my own personal PayPal account to pay, and the order will come through and show up in admin, but don't think it ends up on the right page when it passes the customer back.

    It is a live site, and any assistance would be greatly appreciated.