≡ Menu

WHMCS – “Invalid Token” Error – Resolved!

For the impatient, simply upgrade to at least WHMCS 5.2.2!

Per WHMCS support…

In the latest version of WHMCS we introduced a new session handling class which includes a random session name per install. We also updated the standard WHMCS verify image to use this new class and not call session start itself.

Full back-story and resolution for those not running version 5.2.2, are unable to do the upgrade, or perhaps experienced trouble with this fix.

For the impatient, simply add this line to the end of your configuration.php file.

session_name("WHMCS");

For those interested in the full story …

Since right around the time we installed WHMCS version 5.1.2 in July 2012, we had been receiving an “Invalid Token” error periodically, yet quite regularly, when submitting a form on WHMCS (support ticket reply, invoice, etc.).

We opened a ticket with WHMCS support in August explaining the issue, hoping for that a response that would quickly resolve the issue. Unfortunately, that didn’t happen 🙁 The support team kept saying the error was due to the PHP session expiring and that it was essentially an issue with the hosting provider. With session.gc_maxlifetime set to 24 minutes we were surprised to see the Session ID change after only a few minutes.

In March 2013, our team finally tracked down the cause of this issue …

WHMCS by default uses the PHPSESSID cookie to track its session. If there are any other PHP applications on the domain which use the same cookie, it can cause a conflict which in WHMCS results in an “Invalid Token” error. It took us a while to track this down as the other apps on the domain gracefully recovered from the shared cookie.

To resolve the issue, we added the line of code below to our configuration.php file.

session_name("WHMCS");

Now the session cookie is called WHMCS and does not conflict with the other PHP applications on the domain.

Did this help you? Show some love with a comment!

Comments on this entry are closed.

  • Kevin March 10, 2013, 4:24 pm

    Just so you know, this fix does not fully work. If you add this to your configuration.php, the captcha entries no longer work.

  • Franky Smith March 11, 2013, 4:54 pm

    Hi,

    I’m having the same problem whilst I’m in the admin section of WHMCS. I can access every feature of WHMCS but when I try to save any changes I’m getting the error.

    Any ideas?

    Thanks

  • Laurentiu March 15, 2013, 11:55 am

    Si normal session.gc_maxlifetime la cate minute trebuie setat?
    Am pus “session_name(“WHMCS”);” si tot invalid token primesc.

  • Christien March 16, 2013, 4:25 pm

    No dice 🙁 I can’t even log into the admin panel unless “remember me” is checked on. I get the same attitude from WHMCS though “It’s a php session problem which is the responsibility of your server admin”.

    I pasted your line of code within the php island… any other suggestions?

  • Eric Pretorious March 17, 2013, 8:40 pm

    Thanks for taking the time to document your solution. It didn’t make a difference for me (WHMCS 5.1.3), though.

    Eric Pretorious
    Truckee, CA

  • Mara Alexander April 1, 2013, 7:35 pm

    Thank you! This was driving me crazy. And as you say, it would happen after only a few minutes of being logged in. Everything *else* in WHMCS would work, except for replying to support tickets.

  • Corrado Fiore June 2, 2013, 4:43 pm

    The same issue came up on my WHMCS 5.2.5 install a couple of hours ago. In my case, unfortunately, the fix you’re suggesting didn’t work.

    However, I was able to solve it simply by deleting all PHP sessions on my server AND the cookies on my browser (just deleting the session files didn’t work).

    Of course, I’m not implying that your suggestion is worthless :-), just adding a note here in the hope that it can be of help to someone.

  • Nick August 1, 2013, 5:08 am

    and set the permissions of /var/lib/php/session to 777

  • Kimmo Hedman October 28, 2013, 9:53 am

    LOGOUT and then LOGIN , that resolved same problem for me…

  • rogger November 22, 2013, 5:33 am

    Thank you for your help.

  • Richard December 6, 2013, 10:38 am

    This didn’t work for me on the day I made the change, but the following morning it was fixed. I guess it was the session timing out. Thanks for taking the time to share the solution!

  • Matt January 27, 2014, 8:40 pm

    This should hopefully fix the issue, keeping the sessions managed only by WHMCS.

    1. Create a new directory called ‘session’ and make owner/group writable.
    2. open configuration.php and add the following:
    session_save_path(__DIR__ . “/session”);
    ini_set(‘session.gc_probability’, 1);

    3. Open /.htaccess and add the below for security:
    RewriteRule ^session/(.*)$ /index.php

    • Javier Mendoza April 10, 2014, 2:23 pm

      It worked for me, nice job!

    • zee August 14, 2015, 12:17 am

      u awesome it worked

  • Dan March 29, 2014, 5:40 am

    I’ve got this problem after i’ve updated the PHP on my server. The postinstall script resets the permissions of /var/lib/php/session folder. Correcting this has made WHMCS work again as it should. Setting another (not shared) writeable, individual session save path for the user that WHMCS runs under, will work too (and it’s the recommended way to go).
    Of course, this will be the case of most PHP scripts that use sessions, not only WHMCS.

    • Huw Davies January 4, 2015, 9:27 am

      This worked for me 🙂

  • Mohammad Naji April 29, 2014, 2:44 am

    Perfect!
    Thank you very much

  • CGuizar August 22, 2014, 9:23 am

    Matt

    It is a pretty good solution. Thanks

  • staicu ionut January 11, 2015, 6:29 am

    Hy,

    This problem cam be caused by nginx also wich can use all inodes .
    In our case all available inodes in /tmp are being used up .

    After clearing the /tmp/nginx_client folder all goes back to normal.