"Nonce token is invalid"

(Tom Chadwin) #1

What causes this error? How do I rectify? It's rare, so I've not figured out specifically how to recreate, but it would be good to know some pointers.

(Aleks Bochniak) #2

From our IT guys:

 

Could be many things – would depend when are where its happening – but basically it checks your nonce_token with the sessions bucket in couchbase – it could be invalid due to an issue in the code, permissions not valid, moxi/couchbase issue etc so not necessarily a one solution fits all

(Tom Chadwin) #3

Thanks, Aleks, though since I have never heard of either couchbase or moxi, I'm not sure whether this gets me anywhere...

(Benjamin Pearson) #4

The nonce token is a unique key for your login to stop CSRF attacks on the Matrix backend. It is stored in the session and submitted each time you make a post. Where do you actually see it? In the backend? Also what type of sessions are you running: file or memcache? If you are using memcache there maybe an underlying problem with memcache?

(Tom Chadwin) #5

I think it was seen in Edit+. We are using memcache sessions, and have been having major problems. Squiz are looking into it. I’ll update them with this info. Thanks.

(Scott Hall) #6

The nonce token issue is usually related to server side and/or Matrix stuff. I believe it might be one of two issues:  
1 - An issue with memcache (or the likes) and sessions related gaff that is beyond me, similar issues have been corrected by doing *something like* restart memcache.
2 - The nonce token is automatically added to the js_api.js file generated by Matrix and is appended to each js api request. Matrix *should* be sending no cacheable headers for the js api to avoid problems like this. Might be worth having someone review the request/response for the JS API url in that system to see if it is or isnt. If it isnt, then it could be an older Matrix system or maybe there is something in a reverse proxy config forcing it to cache.

 

That's to possibilities that I have come across the most with edit mode nonce issues.

 

Did you just upgrade?

(Amurray) #7

Agreed. Its a mix of the relationship going on between memcache, session replication, any load balancers, and Single Sign On (SSO).

To quote Nathan,

users in question are changing their session in the middle of the transaction. Because the security token key is stored in the session, this does not match with the one on the new session, and the error results.

If your cms requires your own authentication before you log in as either, your session may still use (and switch back to) your ldap or original account in a brief short time. We have seen it with sys admins who also have ldap back end accounts. (We have it set up so one is viewed up top within the admin interface as "Last Name, First Name" and the other "First Name Last Name" when logged in, a quick refresh and you see they have switched.) Patience before running a long process when first logging in, to confirm no switch, before running long processes has been the main fix.

 

Another possible switch point is when  /_admin and /_edit are both open in the same browser too, that kicks you out of locks, hipo processes and the like with multiple accounts.

(Tom Chadwin) #8

Thanks for all the info, everyone. I don't believe SSO or load-balancing are an issue, but will double-check with the user. Login to _admin and _edit in one session is a possibility. As I say, though, we've been having major memcache issues - Squiz have had to script a daily restart to try to mitigate. I'll give them this info and point them towards this thread.

 

Thanks again, all.