Invalid CSRF protection token

[HarryAdney]

No idea why I suddenly got this error, so, following advice on previous posts I disabled both CSRF Tokens: General and CSRF Tokens: Domain Checker in the Security  settings. When I try to save the changes I have to confirm my  password, natch - which errors out with the "Invalid CSRF protection token" error message.

I've tried this in Edge, Chrome and Opera with exactly the same results.

Any way around this?

 

Version info

WHMCS: 8.8.0
php: 7.4.33

Edited March 5 by HarryAdney
Added version info

[RadWebHosting]

This issue normally indicates session errors with the session.save_path value. You can check these values with phpinfo(). Make sure the session.save_path value exists, is valid, and is not full (as this would prevent saving of the session).

We've noticed events like WHMCS updates, PHP updates, server migrations, and others can cause this type of problem. This error can often be missed during any testing after/before/during the above events if admin is using the same browser as previously cached cookies and authentications may continue to work for some time even when the session.save_path values are incorrect.

Use the phpinfo.php method to check and verify the values affecting your WHMCS, by following the steps provided in the WHMCS root directory: https://radwebhosting.com/client_area/knowledgebase/149/View-Server-PHP-Environment-with-phpinfo.php.html

Hope this helps!

[HarryAdney]

Thanks for your reply, mate. Yeah, the interweb's full of the same advice, unfortunately I can't get access to my host's php.ini. There's a UI to change the settings, though. I did notice that the session.save_path shows a folder below the php.ini containing folder (/opt/alt/php74/var/lib/php/session), but the include_path is set to a folder above it: (.:/opt/alt/php74/usr/share/pear). The fact that both paths contain /opt/alt/php74 makes me wonder if one of them is wrong, presumably the session.save_path because it references a path that doesn't seem to exist  as far as I can  tell. 

[HarryAdney]

On 3/6/2024 at 10:30 AM, HarryAdney said:

Thanks for your reply, mate. Yeah, the interweb's full of the same advice, unfortunately I can't get access to my host's php.ini. There's a UI to change the settings, though. I did notice that the session.save_path shows a folder below the php.ini containing folder (/opt/alt/php74/var/lib/php/session), but the include_path is set to a folder above it: (.:/opt/alt/php74/usr/share/pear). The fact that both paths contain /opt/alt/php74 makes me wonder if one of them is wrong, presumably the session.save_path because it references a path that doesn't seem to exist  as far as I can tell. 

OK, so problem semi-solved. It turns out that a billing module I had installed wouldn't' work with the version of php I was using. Updated to current version but now a compatibility scan shows >200 files that aren't compatible with that one.

Next steps are to contact each of the module authors to see if they have updated versions.

Wish me luck.

I just want to thank my hosting provider's (Krystal.co) tech team for their excellent work.

[RadWebHosting]

5 hours ago, HarryAdney said:

OK, so problem semi-solved. It turns out that a billing module I had installed wouldn't' work with the version of php I was using. Updated to current version but now a compatibility scan shows >200 files that aren't compatible with that one.

Next steps are to contact each of the module authors to see if they have updated versions.

Wish me luck.

I just want to thank my hosting provider's (Krystal.co) tech team for their excellent work.

Yeah, PHP updates and most WHMCS updates typically warrant a full scan of all server, addon, gateway, etc modules (basically any files) that aren't provided by WHMCS directly. Good luck to you! Feel free to post if you run into any issues.