brianoz

Bear's suggestion is critical, and I'd also want to make sure the "admin" user doesn't exist. CSF also has a setting that blocks bots after a certain number of 404s, or you could force a 404 (or 403) in a small bit of PHP code under the old /admin folder, if you want to get fancy. WHMCS has a useful list of hardening suggestions, the majority of these are listed there - worth a read: https://docs.whmcs.com/Further_Security_Steps (You could google "WHMCS security hardening" for a bunch of ideas from around the net) Another good idea, not listed in the above, is to set Basic Auth up on the WHMCS admin directory. That means the first time you access it in a browser, you'll have to enter a username and password. You can share the username and password, or setup a different password for each admin user - just make sure the password has reasonable complexity and isn't 'password123'. (does this method have issues these days? Perhaps someone like bear could update if so, I'm not as much in the loop now I've sold my hosting company). It's also worth knowing that most successful security compromises seem to be around old code that hasn't been updated, rather than people logging in as users. When we had some hundreds of WordPress websites running, nearly all compromises were from old sites, and most were sites where the fixes had been released over a year ago. To prevent this, update your WHMCS regularly so it doesn't get too much out of date. Depending on the newness of the changes and whether they were security patches or major updates, I like to update a few weeks later to reduce breakage risks (other people can find the bugs!). I know WordPress isn't WHMCS, but the concept still applies. Also - backups - I know this is really boring, but always, ALWAYS have "off-server" backups - somewhere else in the internet, not on your servers. Every now and then a company crashes and burns because a dumb bad guy formatted all their servers, you don't want to be caught by that. These backups should be automated but rehgularly checked - automatic backups always seem to break eventually if never checked. I'd take a monthly or bi-monthly air-gapped backup as well - put it on a USB stick, and then put that in a fireproof safe or take it home and store it somewhere safe there. Backups can substantially reduce recovery time in the event of a database or code hack, because they can give you a "known clean" point to compare against. Bearing in mind most of WHMCS is ioncubed, you can always download the latest release and use it to compare or simply overwrite everything with it. And finally - 2FA. I love the idea of a physical key like a Yubikey, as that's the most secure solution, but honestly any 2FA is better than not having anything. You don't have to do this all at once! The summary list is, in rough priority: rename admin folder basic auth on new admin folder Auto Block bots getting lots of 403s and 404s with CSF keep WHMCS updated institute good primary and secondary automated backups, with periodic checks Add 2FA

The $_SERVER variables are only set when a page runs from the web server, as they're part of the Apache API. So nothing in the $_SERVER[] will be set when code runs outside the webserver. When you run a script from hooks, it's nice to log that's what's happened, may help someone understand the context of what is happening in the future (and thus save them time). You could use something like: $servername = $_SERVER['SERVER_NAME'] ?? 'cron/backend'; It would be even nicer to be able to say whether it came from a backend api or cron.

Auto-renewal is supported; this is the whole reason for WHMCS's existence. The best place to start is a the relevant parts of WHMCS' documentation which is fairly clear from memory., although you may also find some stuff via Google ("whmcs auto renewal setup"). You probably also want auto-expiry so unpaid accounts are suspended then eventually terminated. In super quick summary, you should check your config settings, ensure your daily automation is running (9:30am local time is a good time, so you can answer any calls arising), and ensure people sign up to products that have renewal terms. Somebody smarter might respond with better details.

Nobody can help without relevant details such as WHMCS version number. If I remember correctly, there was a bug like this fixed recently, so might be worth checking the release notes.

Amelia: WHMCS John said above that there wasn't an issue and that actual card data isn't stored, at least for Stripe. The only way to know for sure is to check the card related fields in the database occasionally. Worth being aware that the "cardnum" field contains a remote token for most remote gateways, so just check to see whether the data there is an actual card number before panicking.

I'm afraid I can't offer much of a solution, but one starting point would be to enable MySQL's slow query log in /etc/my.cnf or on the MySQL command line. Instructions here. Run a few slow logins, take note of the time, then check out the logs and the output of mysqldumpslow. This tells you which MySQL queries are running slow; and you then can potentially tune or report those to WHMCS and here. You should also submit a ticket to WHMCS asap so they have a chance to follow up. You also need to say which version of WHMCS you're running on?

Surely a better fix would be to move to a transactional email provider that can cope with more than 50 emails at once? Or talk to mailgun and see if they can increase rate limits? (maybe introduce a 1 second sleep between emails, etc). Developing a queuing solution for emails might help, but it's a bandaid approach that just makes things more complex, which usually causes issues down the track.

Yes, there's a reply above, from December (3+ months ago). You might want to ask a question as a new post if you have a related issue, or be more specific about what you were expecting. Cheers!

What specific functionality are you talking about? The more specific you are, the more likely you'll get a meaningful response. (as it is, this could mean absolutely anything)

There are a bunch of possible reasons; first thing I'd check is whether the login page URL has changed, or whether the hook has changed.

To make sure you're comparing appless with apples, you might want to do a dry run to see how long it actually takes for you to replace WHMCS with a manual process, or takes to move to a new open source system. Don't forget to include things like domain renewals, auto-suspension if they don't pay, and some sort of reasonable and robust support system. My guess is you'll find it takes way more time than you'd think, but YMMV.

I'm sorry to partly disagree, but for a WHMCS hook you do need to call the add-hook function to get the code to execute. The code will be READ and loaded by virtue of it being in the custom-hook file (easy to verify by simply including die("---hook code executed---"); in the file!) but if you define a function that function will never get called. Alternatively, you could simply call the function directly, although that's considered bad practice, as you generally want hooks to only run at certain points in WHMCS' execution. If the module you are loading checks for and then calls a PHP function called "preXeroSync()", this is NOT a WHMCS hook, and you are completely correct that it doesn't need a WHMCS add_hook() call to trigger it. The reason it's not running would be one of these: The function isn't defined with the correct name, or namespace, or isn't visible somehow to the module code when it runs. I'd try commenting out the namespace to see if it works without that. The function isn't defined early enough to be visible to the Edgehosting code when it needs to see it. It might be that you need to move the source code to the main hook folder and see if that works. I realize this is way too late to be helpful, but just want to make sure people don't get confused. Looks to me like you had the second case, where it wasn't a WHMCS hook at all; apologies for not catching earlier.

If you use hook code to define a function, that function will never be called unless you either call it in the same file, or use a module hook. In your code, you define a function but it is never called. Pretty sure here that you've misunderstood how module hook code works. The file is read, and it defines functions which are then connected via add_hook() calls. No sweat, this is complex if you're not used to it. 🙂

Looks like you left out the add_hook() call to actually cause the hook to be added somewhere. As you have it, you're defining a function but it never gets called. add_hook("InvoiceCreation", 9999, "preXeroSync"); except that the hook on which you want this to run probably isn't InvoiceCreation, so you'll need to work out what the correct hook name is for your code to work.

The commit causes the changes made by localAPI to become permanent. Changes made after beginTransaction() are otherwise just temporary. If you left out the beginTransaction() method call it would also work. The idea of using a transaction is that changes are rolled back if something goes wrong, and the assumption is that things did go wrong if you don't call the commit() method.