hazzlewis

Our solution, without leveraging reCaptcha: Upon noticing the spam, we implemented a ClientDetailsValidation hook to block fields using chinese characters or the 5666Q.COM and fuli8.tk domains. This worked on our brand running a more recent version of WHMCS (v7.3) but not on our brand running v6.3. Turns out on v6.3 there's a bug where the $vars array passed to the hook doesn't get populated when register.php is called via GET with querystring params e.g., in our server logs we saw stuff like: "GET /register.php?register=true&firstname=%E2%AD%9F%E5%BC%80%E2%AD%9F%E6%88%B7%E2%AD%9F%E5%8D%B3%E2%AD%9F%E9%80%8188%E5%85%83%E2%AD%9F%E7%8E%B0%E2%AD%9F%E9%87%91+%EF%BC%B4%E6%B4%BB%EF%BC%B4%E5%8A%A8%EF%BC%B4%E9%80%9A%EF%BC%B4%E9%81%93+5666Q.COM&lastname=%EF%BC%B4%E6%98%93%EF%BC%B4%E8%AE%B0%EF%BC%B4%E5%9F%9F%EF%BC%B4%E5%90%8D+fuli8.tk&email=73212569%40qq.com&country-calling-code-phonenumber=61&phonenumber=2788930349&companyname=%CE%97%E9%87%91%CE%97%E6%B2%99%CE%97%E5%A8%B1%CE%97%E4%B9%90%CE%97%E5%9F%8E%CE%97&address1=BBX8V+L2RDT&address2=JV6LR&city=HGHGB&state=Victoria&postcode=166226&country=AU&password=KTWx6QSDFf&password2=KTWx6QSDFf&accepttos=on&code=sr7n9&securityqid=1&securityqans=uNLQZt96 HTTP/1.1 So in that same hook, I just dropped in a check to see if $vars is empty, and to populate it with $_REQUEST if that is the case. Then the validation works fine and blocks the registrations. To save people time, here's the hook that solved the issue for us (place it in /includes/hooks): <?php add_hook('ClientDetailsValidation', 1, function ($vars) { $illegalPatterns = [ '#[\x{4e00}-\x{9fa5}]+#u', //checks for chinese characters '#5666Q\.COM#i', '#fuli8\.tk#i' ]; if (empty($vars)) { $vars = $_REQUEST; } foreach ($vars as $key=>$val) { if (empty($val)) { continue; //dont need to do regex match on empty string } foreach ($illegalPatterns as $i=>$illegalPattern) { if (preg_match($illegalPattern, $val)) { return "[{$i}] Illegal value for " . $key; } } } }); Best of luck!

Regardless of whether its happening with gocardless, the fatal error occurs in a whmcs file... Where does WHMCS's onus end?

Honestly i have no idea. All i know is we're seeing this error on attempt capture and i dont know how to troubleshoot it Edit: Does this basically mean im on my own with this?

Hi, we're currently running v5.3.14 and seeing this fatal error for a 'gocardless' service. The full error: Fatal error: Array ( [error] => Array ( [0] => Couldn't find PreAuthorization with 'id'=xxxxxxxxxxxxxx [WHERE "limits"."type" IN ('PreAuthorization')] ) ) in xxxxx/includes/classes/WHMCS/Terminus.php on line 0 The file in question is encoded so im not sure how to troubleshoot it. Any ideas?

Hi, We are already running the cron with the debug flag. Furthermore i was able to use a tick function hack to force error logging, which has revealed no fatal errors when the script ends. Plenty of warnings, notices etc but no fatal error or exception whatsoever. Which leads me to believe there is some code doing an exit; or die; somewhere. The last line in the cron log is: What is meant to happen at this point? Is it likely to run any custom code or invoke any of our custom hooks?

Hi, We are having some problems with the WHMCS cron. We are currently running it with the debug flag, and piping output to a log file. Each night, the cron seems to run up until its last output in the cron log file: "Starting Processing Domain Renewal Notices". After that, nothing. No 'Complete' message, yet no error messages either. Does anyone have any advice for troubleshooting, other than enabling error reporting in our General settings? This is not an option for us. As an aside, it would be great if we could override WHMCS' aggressive error handling. I'd love to be able to enable a level of error_reporting and error_logging without also enabling display_errors... Thanks in advance.