Jump to content

Recommended Posts

The first error I want to post is the cron jobs.

I had it set to 5minutes before, and after upgrading to v7.2.1 I get this error ;

 

 <!DOCTYPE html>
<html lang="en">
 <head>
   <meta charset="utf-8">
   <meta http-equiv="X-UA-Compatible" content="IE=edge">
   <meta name="viewport" content="width=device-width, initial-scale=1">
   <title>Critical Error</title>

<style>
       body {
           margin: 30px 40px;
           background-color: #f6f6f6;
       }
       .error-container {
           padding: 50px 40px;
           font-family: "Helvetica Neue",Helvetica,Arial,sans-serif;
           font-size: 14px;
       }
       h1 {
           margin: 0;
           font-size: 48px;
           font-weight: 400;
       }
       h2 {
           margin: 0;
           font-size: 26px;
           font-weight: 300;
       }
       a {
           color: #336699;
       }
       p.back-to-home {
           margin-top: 30px;
       }
       p.debug{
           padding: 20px 0px;
           font-family: "Courier New", Courier, monospace, serif;
           font-size: 14px;
       }
   </style>

 </head>
 <body>
   <div class="error-container"><h1>Critical Error</h1><p>Undefined index: SCRIPT_NAME</p></div>
 </body>
</html>

 

The 2nd error is this.

I made a fresh new installation and then get the following error when visiting my WHMCS

 

Oops!
Something went wrong and we couldn't process your request.
Please go back to the previous page and try again.

Link to comment
Share on other sites

The first error I want to post is the cron jobs.

I had it set to 5minutes before, and after upgrading to v7.2.1 I get this error ;

 

 <!DOCTYPE html>
<html lang="en">
 <head>
   <meta charset="utf-8">
   <meta http-equiv="X-UA-Compatible" content="IE=edge">
   <meta name="viewport" content="width=device-width, initial-scale=1">
   <title>Critical Error</title>

<style>
       body {
           margin: 30px 40px;
           background-color: #f6f6f6;
       }
       .error-container {
           padding: 50px 40px;
           font-family: "Helvetica Neue",Helvetica,Arial,sans-serif;
           font-size: 14px;
       }
       h1 {
           margin: 0;
           font-size: 48px;
           font-weight: 400;
       }
       h2 {
           margin: 0;
           font-size: 26px;
           font-weight: 300;
       }
       a {
           color: #336699;
       }
       p.back-to-home {
           margin-top: 30px;
       }
       p.debug{
           padding: 20px 0px;
           font-family: "Courier New", Courier, monospace, serif;
           font-size: 14px;
       }
   </style>

 </head>
 <body>
   <div class="error-container"><h1>Critical Error</h1><p>Undefined index: SCRIPT_NAME</p></div>
 </body>
</html>

 

The 2nd error is this.

I made a fresh new installation and then get the following error when visiting my WHMCS

 

Oops!
Something went wrong and we couldn't process your request.
Please go back to the previous page and try again.

 

Check https://forum.whmcs.com/showthread.php?129078

Link to comment
Share on other sites

You know I have never worked out why programmers who obviously are extremely good at what they do don't add a simple rollback and/or re-do update button to their automated update system, it would save a lot of support calls and also a lot of time for users.

Link to comment
Share on other sites

You know I have never worked out why programmers who obviously are extremely good at what they do don't add a simple rollback and/or re-do update button to their automated update system, it would save a lot of support calls and also a lot of time for users.

 

I agree, right now my clients can not access their account and the worst new possible clients can not order.

Link to comment
Share on other sites

I agree, right now my clients can not access their account and the worst new possible clients can not order.

 

Same problem. My client cant place order and also cant login to clients area. Due to that my client complain to domain registry.

Support ticket opened 1 day ago without reply.

Link to comment
Share on other sites

You know I have never worked out why programmers who obviously are extremely good at what they do don't add a simple rollback and/or re-do update button to their automated update system, it would save a lot of support calls and also a lot of time for users.

 

I will have to defend WHMCS on this one. Users are not supposed to run WHMCS in an insecure server. PHP errors set to ON is an unsafe setting for a live site. It should never be on a hosting server that hosts websites to the public.

 

Why are you hosting WHMCS in an unsupported and insecure server should be the question. Because the bug only affects installations with incorrect PHP settings not suggested or recommended by WHMCS.

 

- - - Updated - - -

 

The hot fix doesn't work for me and simply turning off error reporting is not a fix, all that does is hide the fault.

 

You changed the setting, restarted Apache and it's still not working?

Link to comment
Share on other sites

You know I have never worked out why programmers who obviously are extremely good at what they do don't add a simple rollback and/or re-do update button to their automated update system, it would save a lot of support calls and also a lot of time for users.

 

You took a backup before you upgraded, you could have rolled back in just a few minutes.

Link to comment
Share on other sites

Users are not supposed to run WHMCS in an insecure server.

 

Where do they state this?

 

It is upto the user if they secure the server or not, but as it is a client and billing platform then it is good practice to have the domain you host your WHMCS on secured by a SSL certificate

Link to comment
Share on other sites

Where do they state this?

 

It is upto the user if they secure the server or not, but as it is a client and billing platform then it is good practice to have the domain you host your WHMCS on secured by a SSL certificate

 

They say they don't recommend running it like that on the link posted on this thread, and there is more detail as well here:http://docs.whmcs.com/Error_Management

 

 

 

It's common knowledge that your PHP should not be set to display errors in the browser, and neither should Apache. And neither should you leave the debug setting on WHMCS on either. All those debugging settings for software are for testing temporary issues (switch on, test, solve, switch off)..

 

 

The reason is security. Here:

 

 

" standard attack tactic involves profiling a system by feeding it improper data, and checking for the kinds, and contexts, of the errors which are returned. This allows the system cracker to probe for information about the server, to determine possible weaknesses. For example, if an attacker had gleaned information about a page based on a prior form submission, they may attempt to override variables, or modify them"

http://php.net/manual/en/security.errors.php

 

 

 

SSL has nothing to do this. SSL protects the information in transit between your customer's system and your server, it's not a magic solution that keeps your server secure. You are mostly likely going to get hacked by running insecure permission on files, folders or unsafe settings on your server (not patched, open ports, the system showing leaking information, etc.). SSL has zero effect on your server's/website security.

 

 

So it's your responsibility to make sure your servers are properly secure. You should also take at least the minimum procedures to do this if you even care about your customers or users entering information in WHMCS or using your products & services.

 

 

Everything that can fail will probably fail eventually. And this is why you should not display errors on the browsers to visitors with WHMCS. And this is why that is not a suggested configuration either.

 

 

I also disagree with it's up to you to secure your server. If you are using it just for your use, go ahead. If you are accepting for example credit cards, you are required to followed certain security standards, or the payment/bank can close your account with them, and you will not be able to receive online payments anymore. Google PCI scan if you are accepting Visa or Mastercard.

 

 

And even while you can run WHMCS in an insecure setup if you want, no problem. But you can't blame WHMCS for the software misbehaving in such environment because that is not something most people run and they probably didn't test to run like that. If you are not running the suggested and recommended settings for a software vendor, they don't have to support issues in a non-supported configuration either.

Link to comment
Share on other sites

They say they don't recommend running it like that on the link posted on this thread, and there is more detail as well here:http://docs.whmcs.com/Error_Management

 

 

Yes they RECOMMEND, which is different to saying you are not supposed to run it on an unsecure server.

 

you look at it this way, you have a reseller account and have WHMCS installed, then you have no root access to server, so how would you secure a server you have no access too. This is why it only recommended to have a secure server.

 

Luckily i have servers and have them all secure with various lines of security before you can access as root

 

Having PHP errors on has nothing to do with a server being secure or not

Link to comment
Share on other sites

Geesh guys slow down, my servers are secure and I did take a backup before I updated WHMCS, I was simply saying it would be a hell of a lot easier if there was a rollback or reupgrade button in the upgrade section of WHMCS. I really am sorry if you guys misunderstood me or assumed the wrong thing from my post.

Link to comment
Share on other sites

Yes they RECOMMEND, which is different to saying you are not supposed to run it on an unsecure server.

 

you look at it this way, you have a reseller account and have WHMCS installed, then you have no root access to server, so how would you secure a server you have no access too. This is why it only recommended to have a secure server.

 

Luckily i have servers and have them all secure with various lines of security before you can access as root

 

Having PHP errors on has nothing to do with a server being secure or not

 

Since you seem to have reading comprehension problems I will quote what WHMCS John said:

https://forum.whmcs.com/showthread.php?129078

 

"This issue arises when the sensitivity of the system error reporting is set to a high level. If your PHP system error reporting is disabled, this issue will be safely ignored.

 

While we recommend running WHMCS within an environment with error reporting disabled...."

 

I will not bother to reply to the other things as I see that you don't know a lot about computers when you started to mix stuff like SSL is secure and root access in your posts when this issue has nothing to do with neither. It seems you are running from a shared hosting. Otherwise, you would just set your PHP settings correctly. Even the lowest garbage hosting providers today allow even with shared hosting to set the php.ini settings per account, and no serious hosting company in a shared environment does this globally for all users. Assuming you are dumb enough to run your billing system on a shared server in the first place...which is a NO, NO for any company that is even serious about protecting its customer data. I feel sorry for your clients based on your knowledge about basic security...

 

- - - Updated - - -

 

Geesh guys slow down, my servers are secure and I did take a backup before I updated WHMCS, I was simply saying it would be a hell of a lot easier if there was a rollback or reupgrade button in the upgrade section of WHMCS. I really am sorry if you guys misunderstood me or assumed the wrong thing from my post.

 

No problem :) but there is no need to do that. Just set your PHP setting correctly and apply the fix and the problem should be fixed.

 

 

Rolling back would be far more complicated and messy once you upgraded, in particular, because your database was already updated as well to the new version as well, so it's not just rolling back the files but also the database would need's to be reverted. At that point, you are better just doing a restore from your own backups if something went terrible south with your upgrade.

Edited by yggdrasil
Link to comment
Share on other sites

Same issue here, still working on fixing it, I'm out of ideas though and waiting on a ticket response. The Admin area works fine, so I went a day thinking the upgrade went fine, when in reality my entire client area was down and caused a massive loss due to a weekend promotion.

I will now be checking every client function manually each update, even minor ones, from now on. More work, but seems to be a common issue with WHMCS.

The hotfix did not help.

 

Also, isn't this against their own instructions?

 

----

Special Note About Error Reporting Level

 

We recommend that you do _not_ change the $error_reporting_level within configuration.php or the corresponding PHP ini error_reporting directive at the environment level, during normal production or staging operation.

 

Specifying a more sensitive $error_reporting_level, which observes non-critical warnings and notices, may result in pre-mature exit and prevent normal production behavior from functioning properly.

Edited by KevinR
Link to comment
Share on other sites

Anyone looking into this?

Business has been offline for the entire weekend and no response.

I can't roll back that I know of, as backups don't have all the new clients, payments, invoices, etc.

I do have full backups, but they are now 4 days old.

Link to comment
Share on other sites

yes yggdrasil, but you stated

 

Users are not supposed to run WHMCS in an insecure server.

 

which is different to PHP errors being enabled or disabled

 

so i ask again where does it say WHMCS must be run on a secure server, bear in mind that all WHMCS installations are not all run on VPS or Dedicated servers, so users running WHMCS on a reseller or master reseller plan dont have server access

Link to comment
Share on other sites

1) PHP errors On = Insecure Sever Configuration

2) Shared Hosting = Insecure Server for an e-commerce site that accepts credits cards payments

 

1+2 = Insecure Server.

 

WHMCS not suggesting to run a secure server? Wait, isn't that common sense? If you buy a car, do you expect the shop to tell you not to drive drunk?

 

 

Sure, you can drive drunk. And sure, you can run WHMCS on any server you like, and as insecure as you want as well. It is your data, and your customer's data after all. Just don't come to WHMCS and complain after that claiming that WHMCS is insecure and you were hacked, or that it's unstable and buggy. Companies can be held liable now for security breaches if they were aware of the security issues and did nothing to prevent them.

 

 

If someone is telling you that running PHP with errors on is insecure, you should take that advice and fix it, not try to argue that it's not unsafe. Even the PHP official developers on their site are you telling its insecure and can lead to information leaks or worse, exposed vulnerabilities, but again, you didn't even bother to check that link it seems :crushed:

Link to comment
Share on other sites

Check that your error_reporting really is set to 0.

 

I was getting an Oops error so I explicitly set error_reporting to 0 in configuration.php. However, I was running PHP in php-fpm mode (FastCGI probably has the same problem) and if you look at the phpinfo() output it was ignoring what I had set in configuration.php and also in a local php.ini and using the servers master value of E_ALL!

 

For me, it caused the cart to throw an exception (it passes a null to a foreach) and a couple of 3rd party modules barfed out too.

 

I'm deftly sidestepping the debate as to why WHMCS now throws so many exceptions into the Whoops handler and why their developers haven't spotted their coding errors by running with E_ALL on in development/beta testing to weed out these.

Link to comment
Share on other sites

1) PHP errors On = Insecure Sever Configuration

Wrong! Errors being displayed does not make something 'insecure'. A server is not secure simply because errors are hidden. Sorry, but that's just dead wrong.

 

2) Shared Hosting = Insecure Server for an e-commerce site that accepts credits cards payments

Again, dead wrong

Of course, the shared environment is not going to be PCI compliant, HOWEVER, you don't need to be PCI compliant in order to process CC payments. That's what tokenized gateways are for.

Link to comment
Share on other sites

All error_reporting turned off at the server. Cron job set to run every 5 minutes as suggested. 7.2.1 hotfix applied. Mailbox is still full of cron warnings and our 1AM daily processing hasn't worked in days. No response to tickets.

 

Ridiculous!

 

We've been using WHMCS since the beginning, and the lack of proper QA, unit, and regression testing after all this time is inexcusable. Perhaps you folks might want to re-focus on making your product reliable and dependable once again instead of devoting all your resources to monetization.

 

Just a suggestion from someone who has been making software since before PHP was even a thing.

Link to comment
Share on other sites

The issue ended up being that langupdate.php was not deleted during update.

However, when I checked, that file was not there, and the issue persisted.

 

I finally got a response to my ticket about this, and once I gave them credentials they were able to quickly fix it.

Though the fix applied, didn't make sense as I had already done their instructions.

So I am back online now, and lost out on a summer sale advertisement 100%.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use & Guidelines and understand your posts will initially be pre-moderated