Jump to content
Enzo79

Site been working for a year, now broken!

Recommended Posts

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.

Share this post


Link to post
Share on other sites

Share this post


Link to post
Share on other sites

@Enzo79

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

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

M


Get the latest Responsive osCommerce CE (community edition) here .

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
7 minutes ago, Enzo79 said:

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

Speak to your host, most good hosts will have nightly or weekly backups you can restore from. You may even find that you can do it yourself, check in your control panel.

As you don't know what caused it, just restoring may not help but it's worth a try. As you think 2 key changes were made.  First I would roll back the php update. Check with your host most now allow you to use the php version you require. If that makes no difference, then check the ssl you indroduced even turn it off for a while and check.

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:

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

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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]

 

Share this post


Link to post
Share on other sites

!on and off should be equivalent, unless you have a very strange server setup.

^(.*)$ and (.*) should both capture the entire REQUEST_URI (sans initial /) into $1, but the first form (with anchors) may be a bit more reliable in capturing the entire string. Since you're using %{REQUEST_URI} instead of /$1 in the rewrite, the $1 capture is ignored anyway.

Do you have any subdomains or add-on domains in play here? %{HTTP_HOST} is what the visitor entered, not some canonical form of your domain name. For best SEO results, you really should pick "with www" or "without www" and stick with it, adding the test to this redirect (with [OR]) so that you end up sending only ONE redirect request (search engines penalize you for multiple redirects, say, one to change http to https and another to add or drop www).

An explicit R=301 tells search engines that the resource has been permanently moved, and the new URL should be used from now on. The first one gives an implicit R=302, which is a temporary move, and should not be remembered. The [L] flag is a convention to tell .htaccess processing to leave and come back in (start over from the beginning). Whether it makes any real difference depends on what other URL rewrites/redirects you have in your .htaccess.

A "500" (Internal server) error can be caused by a lot of things, including a botched .htaccess or php.ini file, or sometimes PHP code errors. Do you have any php_value or php_flag entries left in your .htaccess? They belong in a php.ini file (or equivalent). Your host should be able to tell you how to turn on enough error logging to find the problem, and what files (e.g., "error_log") to look for.

Edited by MrPhil

Share this post


Link to post
Share on other sites
4 hours ago, Enzo79 said:

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

RewriteCond %{HTTPS} !on

Is known to have issues on some server set-ups and can misbehave.


 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

Trying to remotly debug like this is never going to be easy. If you think its the .htaccess then just remove everything and add it back one rule at a time to see whch is the problem.

You shoud not need this?

<IfModule mime_module>
AddType application/x-httpd-ea-php72 .php .php7 .phtml
</IfModule>

This is questionable do you know why your using it?

"The ETag HTTP response header is an identifier for a specific version of a resource. It allows caches to be more efficient, and saves bandwidth, as a web server does not need to send a full response if the content has not changed. On the other side, if the content has changed, etags are useful to help prevent simultaneous updates of a resource from overwriting each other ("mid-air collisions").

If the resource at a given URL changes, a new Etag value must be generated. Etags are therefore similar to fingerprints and might also be used for tracking purposes by some servers. A comparison of them allows to quickly determine whether two representations of a resource are the same, but they might also be set to persist indefinitely by a tracking server."

<IfModule mod_headers.c>
  Header unset ETag
</IfModule>
FileETag None

 

Edited by JcMagpie

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Quote

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.

Almost. It says to associate .php files (and .php7 and .phtml, which you don't use) with PHP 7.2. Removing or commenting out this line would drop you back to the default version of PHP.

Quote

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

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.

Quote

The next bit is the redirect to make sure everything is .https

As written, it might well work OK, but I'll give a caution: for best SEO, you want to be consistently mydomain.com or www.mydomain.com. 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. Something like:

RewriteEngine On
RewriteCond %{HTTPS} !on  [OR]
RewriteCond %{HTTP_HOST} !^www\.  [NC]
RewriteRule ^(.*)$  https://www.mydomain.com/$1  [R=301,L]

Note that your domain is hard coded (this is the "with www" way) because HTTP_HOST can be mydomain.com or www.mydomain.com, and you can't simply shove a www. in front of it. If you want to use the "without www" form, you would take the ! off the HTTP_HOST line and remove www. from the rewrite. The R=301 tells search engines to index this revised URL instead of what they had before.

The ETag business I don't quite understand, but if your host put it there, presumably it's OK. The cached file expiration stuff is to cut down on files being fetched from the server (performance improvement), ranging from 2 days to a year (depending on how quickly a file is expected to change).

Quote

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.

Yeah, f***king script kiddies trying to find vulnerable WordPress sites and break into them. "Throw it against the wall and see what sticks". I wish I could slit their bellies open and throw them into a shark tank... at least that could provide some amusement.

At least you found that your database somehow got corrupted and your PayPal entries removed. It would be a good idea to figure out how that happened, to avoid a repeat. At the very least, learn to keep file and database backups on your PC so you don't have to keep going back to your host to do it for you. And learn how to restore files and database!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

If it's commented out, you can safely delete it, as it's not being used. The only reason to keep something around would be if some time in the future you might want to use it again. php_value and php_flag are things you'll never use again in an .htaccess file, so go ahead and trash them. If civilization comes crashing down and you have to revert to PHP 3, you can always recreate those lines.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×