[Site been working for a year, now broken!]

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.

[Cannot make TLS 1.2 work]

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?

[Cannot make TLS 1.2 work]

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 2.3.4.1
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.

[Site been working for a year, now broken!]

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.

[Site been working for a year, now broken!]

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?

[Site been working for a year, now broken!]

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
</IfModule>

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>
#</IfModule>

# 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
</IfModule>
FileETag None

## EXPIRES CACHING ##
## 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"
</IfModule>
## EXPIRES CACHING ##

<Files 403.shtml>
order allow,deny
allow from all
</Files>
deny from 46.229.168.65
deny from 46.229.168.66/31
deny from 46.229.168.68/30
deny from 46.229.168.72/30
deny from 46.229.168.76/31
deny from 46.229.168.78
deny from 46.229.168.79
deny from 46.229.168.80

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.

[Site been working for a year, now broken!]

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}

vs

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

 

[Site been working for a year, now broken!]

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.

[Site been working for a year, now broken!]

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.

[Site been working for a year, now broken!]

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. 

[Site been working for a year, now broken!]

9 hours ago, Jack_mcs said:

Does the ssl test in admin->Paypal->Configure->general pass? 

It all seems fine to me...

cURL Version: 7.59.0
cURL SSL Version: OpenSSL/1.0.2o

Default Setting: Success
TLS v1.2: Success

[Site been working for a year, now broken!]

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.