"invalid security token" error message can happen with any version of Joomla. I can't remember the specifics of why, If I remember right it was something to do with your browser. Once you get the message you just need to do a hard refresh of the page. usually just removing the index.php from the admin url in the address bar and so that your just left with [your domain]/administrator
press enter and you should be able to log in.

On a side note, considering that this is a session issue... I wonder if there is some relation to this other session related issue. #8757

Same issue for me...

Clear your cookies and try again.
Clear your database table #__session and try again
Post results here.

What PHP version?
What web server are you using, and version (apache/nginx ubuntu/centos) ?
What session handler are you using?
Whats your session time?

@PhilETaylor I have see this issue in every Joomla version since 1.6
happens with IE, Chrome, Firefox, Edge
every php version 5.3→5.6
apache servers
WebServer to PHP Interface cgi-fcgi
MySQL
database session handler

I just had this come come up 30 seconds ago when I checked what session handler we use (Joomla default database session handler)

Following the steps I listed in the post above, the issue goes away (until the message comes up again and I have to repeat the steps again).

Me too having the same problem after upgrading to Joomla 3.4.7 on my localhost

I was doing some development on my custom component and all of a sudden it throws 'Invalid Token' when I try to login from front-end. No luck and I am not able to login :-(

Joomla 3.4.7
Windows 8.1
Xampp 3.2.1

Update: It works now after clearing the Cookies.

We've just created a 3.4.8 Release Candidate Package (https://github.com/joomla/joomla-cms/releases/tag/3.4.8-rc). Some of these session issues are not reliable - so just give it a try and see if you come across any issues :)

I have cleared my cache on FF as well as on Chrome, went into the database and changed my password and also created a new superuser but still I'm getting the "invalid token" message when I try to login

Cleared database table #__session
Joomla 3.4.8 (the error started when I updated from 3.4.6 to 3.4.7)
Php. 5.3.1.9
Apache 2.2.23
MySQL 5.5.27
Session handler Database
session time 180 (yeah I know thats too ong)

clear your COOKIES (not just your cache) in your browser.

Did that and still doesn’t work…

On 28 Dec 2015, at 13:51, Phil Taylor notifications@github.com wrote:

clear your COOKIES (not just your cache) in your browser.

—
Reply to this email directly or view it on GitHub #8766 (comment).

Try Clearing your sessions table in your database.

Did it, unfortunately didn’t work….

On 28 Dec 2015, at 14:03, photodude notifications@github.com wrote:

Try Clearing your sessions table in your database.

—
Reply to this email directly or view it on GitHub #8766 (comment).

Try downloading the full Joomla! 3.4.8 install (not the upgrade packages) and copy the files over the top of your site (be sure to skip or remove the install folder and install files).

Also, clear your #__session table in your database after copying the files.

I'm facing this error after updating to 3.4.8
This happens when someone is trying to login the administrator area or navigating the frontend.
I don't know if is a bad server configuration or what.
I've cleaned the cookies, session table is empty also.

Warning: base64_decode() has been disabled for security reasons in /home/traductionis1896/public_html/site/libraries/joomla/session/session.php on line 658

Fatal error: Call to a member function get() on a non-object in /home/traductionis1896/public_html/site/libraries/joomla/session/session.php on line 499

Fatal error: __clone method called on non-object in /home/traductionis1896/public_html/site/libraries/joomla/session/session.php on line 386

"base64_decode() has been disabled for security reasons "

Get a better web host. No, get a reputable web host. Even the bad web hosts know not to disable base64_decode() for security reasons - absolutely pathetic!

LOL they might as well disconnect their server from the net for "security reasons".

They enabled it again. I' not sure what will I do with more than 60 Joomla sites on the same server...But it's working now. Argentina's rules: If it doesn't work, drop it!

Yeah did that and that also did not work, it actually screwed up the the hole site… :-(
Still having the problem though!!

On 28 Dec 2015, at 17:58, photodude notifications@github.com wrote:

Try downloading the full Joomla! 3.4.8 install (not the upgrade packages) and copy the files over the top of your site (be sure to skip or remove the install folder and install files).

—
Reply to this email directly or view it on GitHub #8766 (comment).

I'm facing the same problem on 1 site, of several, and I'm not able to figure out where it's coming from. There is two Joomla sites on the same hosting account, same server environment, just separated web roots. The one being OK is built on 3.x, the problematic one has previously been updated/migrated from 2.5. I can't see any extensions influencing on sessions, especially not for both admin and site, as login is broken for both.

Clearing browser, session table, cache folders, and also turning of cache doesn't change anything. Even changing computer doesn't make any difference.

To get to the bottom of this this Im offering to look into this for FREE for you. Please send me your site details using the form at https://fix.myjoomla.com/now and I'll take a look for FREE - note who I am. I'm pretty darn sure this will not be a Joomla issue at all.

Interestingly, I once again got the "The most recent request was denied because it contained an invalid security token. Please refresh the page and try again" message in J3.4.8.

Suspected replication steps,
1. Login to joomla admin (with a short session)
2. Let your session expire and get yourself droped back to the login screen
3. Put your computer to sleep/hibernate
3. When your well past the session expire time, wake up your computer
4. From the open browser tab with the login screen try loging in again

As always, removing the /index.php from the url and pressing enter will force a reload of the page and session allowing login

I would say that is perfectly expected behaviour as the cookies you have are expired but yet you are trying to use them!!!

I should point out that your "security token" (for CSRF protection) and your Session token/cookie - are two different things...

Yeah, the "issue" of @photodude isn't the same as @bostmaguy and others are facing after the update.

Regarding debugging I "sadly" don't have a site to offer any longer, as I finally got it working. Not sure how yet, but there seems like there was some leftovers and duplicates from Akeeba (like FOF listed with two versions). After uninstalling Admin Tools and Backup, I removed the duplicates/leftovers, before reinstalling the components. After that the update didn't cause any token trouble?!

Will try to replicate it on a backup restored to alternative location when (if) I get any time for it in the new year...

For the record, the message displayed is from the lang def JINVALID_TOKEN

@syntaxerror from the language files,
JINVALID_TOKEN="The most recent request was denied because it contained an invalid security token. Please refresh the page and try again."

Note: you can't "refresh" the page with the browser refresh button or by hitting the f5 key.
you will be blocked from loging in, stuck on a white screen with only this message. Effectively unable to login to the site.
You can however force a hard refresh by removing /index.php and hitting enter, at which point you will be logged in (no retyping of the user name and password)

No, it's not the same thing you're talking about. And no there is no way to do any hard refresh etc. on this issue. As I mentioned, the "issue" you described above isn't the same. And from the responses around, your "solution" doesn't help. No offence, just stating it.

Btw! In frontend JINVALID_TOKEN is simply displayed as "Invalid Token". I just mentioned the def in case anyone would like to peek at the code, to see where and when it's triggered. I'm well aware of the translations of it. :)

ok I just investigated one of these "I cant login" issues for a client

If you are having issues logging in, please, edit your /configuration.php and tell me (here in the issue) what your setting is for

public $session_handler = 'database';

Please also confirm or deny if your web host is Siteground.

Hi Phil,
I have: public $session_handler = 'database’;
And my host is not siteground, its: keurig online

On 31 Dec 2015, at 16:22, Phil Taylor notifications@github.com wrote:

ok I just investigated one of these "I cant login" issues for a client

If you are having issues logging in, please, edit your /configuration.php and tell me (here in the issue) what your setting is for

public $session_handler = 'database';

Please also confirm or deny if your web host is Siteground.

—
Reply to this email directly or view it on GitHub #8766 (comment).

Thanks - Im investigating an issue with the memcached session handler at the moment - but if you are set to database then thats not your issue - my previous offer to investigate on your site for free stands.

Super, thanks! Ill send you the details through the link you sent me tomorrow.

Have a great new years eve!

On 31 Dec 2015, at 16:28, Phil Taylor notifications@github.com wrote:

Thanks - Im investigating an issue with the memcached session handler at the moment - but if you are set to database then thats not your issue - my previous offer to investigate on your site for free stands.

—
Reply to this email directly or view it on GitHub #8766 (comment).

@syntaxerror from everything I can tell it's triggered by com_login at line 50

Basically it's failing the token check from JSession, and exiting with the notice JINVALID_TOKEN
looking at JSession::checkToken() I would guess something is causing it to fail to get a session resulting in the session not being new (if session is not new returns false).

@photodude Load up your /administrator/index.php - view the source - find the token in the login form - refresh the page - does the token change or stay the same? It should stay the same...

If it changes then you have a server session issue - what is your session_handler in /configuration.php

E.g. If it changes like this then you have a session issue: http://screenshot.myjoomla.io/3U3U1w0q1M1m

Having investigated (for free) the issues reported by @stevensandberg I'm pleased to report that this is 100% nothing to do with Joomla and 100% the fault of extension developers accessing and manipulating the $_SESSION object directly.

Specifically, the antispambycleantalk from cleantalk.org with code https://gist.github.com/31bf9127127a9eaf886c is manipulating the $_SESSION object.

Please note that this is fully covered by the FAQ for Joomla 3.4.7 ! https://docs.joomla.org/J3.x:Backward_Compatibility_in_Joomla_3.4.7

As soon as I disable this extension on this site (clear my cookies to clear my session, then reload the admin login page) I was able to login without issue to the Joomla Admin Console and all the session issues were resolved.

@bostmaguy Are you still having issues or can this issue be closed now?

Yes. Once I cleared out the session table in the database, I was able to log into the admin backend. Does anyone know when Joomla is going to have a built-in commenting system as JComments is getting long in the tooth, isn't as mobile-friendly as it should be, and has the worst captcha system that I finally had to shut it off (based on users complaining they couldn't read it) and purchase and install Clean Talk anti-spam plugin for JComments. BTW, Clean Talk plugin is getting blamed for the session issue, but I hope people are using the latest version that came out a few weeks ago.

Excellent thanks for confirming that its working for you (I'll page @brianteeman who can close this now as I dont have permissions to do that).

I don't believe there are any plans for a commenting solution to be added to Joomla core - however I'm often proved wrong.

No plans for one as of present or for the foreseeable future

@bostmaguy there are a number of other options for comments in the JED

Hi Phil,
I had the same login issue today, after upgrading to 3.4.8. I tried to delete records from jos_session table, tried to connect from the clean VM which has no cookies / browse history in it, the result was the same.
and then I found this discussion, and noticed that cleantalk extension was blamed. I have it installed, so I disabled it from jos_extensions table, and after that the problem disappeared!

Thank you for providing the solution!
Ravil

@RavilN I'm glad that you got your issue sorted, please be sure to drop a note to the developers of the antispambycleantalk plugin to tell them of your frustration - the more people that do that the better the chance their developers will fix their incompatibility.

Done, have sent them the message.

Hi everybody. I'm from CleanTalk tech support. Thank @RavilN for letting us know. Our programmers said that we fixed this bug already. To fix that you must delete CleanTalk folder and install newer version.

Thank you so much @PhilETaylor for solving this problem. The whole day I was looking for the solution after upgrading my site to Joomla 3.4.8 and finally, my problem is gone.
Thanks again.

You're Welcome :) @nehaharish

Still happening in 2020.

Fix is to clear #__session table in db, and change browsers/try in incognito because clearing the cache ("Hard reload") in Chrome doesn't help. What's funny is that the token is actually changing between attempts but it still failed, I was debugging the checkToken function in login() so i can confirm that.

If you are still having a problem in 2020, then the root cause of your problem is probably not the same as this issue.

You are best seeking support from the Joomla Forums

Happens on Joomla 3.9.18 Stable | Amani | 21 April 2020 19:30 GMT So i suspect this is still an issue. Might be a Joomla core issue, or possibly a plugin like Akeeba or similar "security" plugin tampering with the token, and then #__sessions persisting through a database import/export... I experienced this in development too like previous users, not on live.

Well if you are running out of date and insecure Joomla 3.9.18 you should not be reporting issues. Upgrade to the latest version of Joomla and test with that, if you can replicate a problem, and can reproduce it over and over, then open a new issue here, do not hijack a 5 year old issue that is already PROVEN not to be a Joomla issue, and PROVEN to have been fixed.

Secondly, please refrain from making wild accusations and assumptions about rock solid award winning software like Akeeba. I can assure you that Akeeba is NOT making any changes to the Joomla Session directly or manipulating the CSRF Token. Read the code.

Almost 5 years ago I personally looked into this users reported issue, and the problem was with antispambycleantalk from cleantalk.org. This is and was, not, a Joomla core issue.

All above said, as this issue happens in administrator\components\com_login\controller.php: login() function and it's $this->checkToken('request') line, this smells to me like a Joomla core issue. As mentioned before, I suspect a session from previous dev env got saved in db for admin user and joomla refuses to release that session... So, it looks like a CRSF forgery i suppose, but Joomla should still respect the changing token it itself gives out into the form before trying to login. This is a bug.

More wild assumptions you are making... Im sorry, Im out.

@Griefchief as phil said, update your software to the most current version(s) including php, apache & extension(s) and then if you still have an issue you can replicate, open another ticket and tag me personally.