Could not verify the security token on this form when activating plugin

[Findus23]

People have been reporting this for a long time (maybe #14556 and others) and it happened to me quite often, but I could never reproduce it until now:

When updating/activating a plugin one clicks on the button and immediately gets to a page showing

Could not verify the security token on this form

after going back to the plugins page and trying again it works most of the time (but not always).

I think I have now found a way to reproduce it (as in I could reproduce it multiple times in a row, started screen recording and then had to try multiple times to get it on video once)

Matomo.bug-832p.mp4

I think what is causing it is the following:

• People click on the cog icon
• they get to the admin page with widgets loading
• they click on plugins before they have finished loading (and see Display the "oops" red error message, only when there was an error, do not show it when user clicks away to load another menu or page #10578)
  (and this is where my guessing begins)
• sometimes the system check takes quite some time due to the disk being slow (cache system check results #14340)
• the plugins page loads before all previous PHP processes have finished
• the nonce calculated for the plugins page is not the last one calculated and therefore not valid anymore (?)

What speaks against this theory is that one time it happened without the admin homepage and just dis- and enabling a plugin quickly (see the end of the video)

potential reasons why this could not yet be reproduced:

• poeple are running Matomo on very slow servers
• when development mode is enabled Matomo is installed from git, integrity checker is skipped, but would otherwise take a lot of time
• the more often one tries, the faster integrity checker runs due to disk caches
• I click too fast :)

[tsteur]

integrity checker is skipped which takes a lot of time

Which integrity checker do you refer to? When is this executed?

[tsteur]

FYI tempted to move this to priority backlog since it's working in general and maybe not too important compared to other issues we have open. Unless they always run into this issue maybe?

[Findus23]

Which integrity checker do you refer to? When is this executed?

The system check that compares all files to the expected hash. As it needs to read every file it can take a few seconds on slow disks.

It is executed by the System Check widget on the admin home page (unless Matomo is installed from git) (improved wording above)

[tsteur]

@Findus23 I can actually not reproduce it. The NONCE is actually not expiring after 1 hop but after 600s = 10 minutes. Also it appears on the admin home page, there is no widget requesting any nonce that could potentially overwrite a different nonce.

Also tried several time deactivating, activating, deactivating but always worked no matter if dev mode was enabled or disabled. With and without marketplace enabled.

[Findus23]

I'm also out of ideas. As the fix for this would not be a breaking one, we could fix it in 4.1 or later once we know the reason. Until then, I'll refer everyone with that issue here and maybe we will get more information that helps reproduce it.

[nomandera]

FWIW I often see this issue and was solving it previously by logging out and back in again. Having read this ticket I now realise that I am racing; being so used to navigating to the pages I need.

This morning logging out and back in several times did not work for me so after reading the above advice I logged out, logged in and waited until everything was clearly loaded. The next attempt to update an addon worked perfectly.

Anecdotal evidence I know. Caveat I am running 3.13.6 whilst waiting for the deb package updates to make it live.

[Findus23]

Yay, I'm not alone!

Indeed there seems to be some weird race condition that only occurs in some setups.

[asuckar]

I am not sure if this is related to your case or not but It is always good to talk and spread every single information that may help, I faced the same issue today while trying to update matomo to the latest version and I noticed I was using Safari iOS “Private Mode” and repeated that 5/6 times but always failed with the same error about “security token” and i suspected it may be due to the lack of cookies permissions or something similar so I tried to login on the same device (iOS) Safari but without “Private Mode” and after login, the first trial it showed me the same error but the second trial worked great and updated successfully as if the first trial wrote something and were not able to read it and the second trial read it successfully and were able to update my installation

Note: this may be a coincident and not a rule but as mentioned any small detail may help sometimes

[nicobilliotte]

same problem…, matomo worked great on "slow server" in 3.0, migrated to 4.0, then migrated on new server with SSD drive, everything run fine, no errors, good rights whatever you want, but we have this message "Could not verify the security token on this form"
Running on php FPM 7.3, mariadb 10+… Tons of ram… Moreover Matomo does not log new visits ! on 60 websites more than half have 0 inputs, when the WP plugin list visits… What is wrong ?

[nicobilliotte]

OK find something ! file structure is like : /var/www/domain
then sub directories :

• web
• private
• logs
• tmp
• ssl
• …
  so to protect tmp dir & to ensure privacy I moved tmp_path from /tmp to /../tmp , it works on paper… but not in matomo causing wrong token check issues

changing path to /var/www/domain/tmp solved this problem

[devlinrcg]

@tsteur I can confirm this behavior with the following:

Version 4.2.1:

• I'm unable to reproduce the error;

Version 4.3.0:

• I was able to reproduce the error when navigating/clicking at a fast pace inside Matomo;
• I was not able to reproduce the error when navigating/clicking at a slow pace inside Matomo;

Version 4.3.1:

• I was able to reproduce the error when navigating/clicking at a fast pace inside Matomo;
• I was not able to reproduce the error when navigating/clicking at a slow pace inside Matomo;

In my test environment I have Matomo not open to the Internet, and I see that the diagnostic that checks if server directories that should be private are accessible introduced in 4.3.0 have a delay of at least 2 seconds within the system check. If I set the access to the Internet (ingress), the system check passes and I don't get the error at all.

In my particular case, it seems that there is something related to a normal/fast pace navigation and this system check when Matomo is not open to the internet (which will fail the diagnostic for directories mentioned above). Could be related to the race condition mentioned by @Findus23.

Editing: Currently this test environment is behind a Load Balancer.

Hope this helps shed some light on the issue at hand.

[Tazzios]

running multiple instances on 4.4.1
environment windows,iis,mariadb,php8 and a LAMP7.4

I was busy with the google analytics importer and I got the error every time i tried to upload an configure file. Logout and in did not help and private browser mode also didn`t.

I went to phpmyadmin en cleanup all records(around 40) from the sessions table and after that it the error was gone.
An other instance had 155.058 records, which does not look healthy to me.
Lifetime column as value 1209600 oldest record(the other date column) was from 10-08-2021

If the error popups again, I will let you know.

[webcoreinc]

This is definitely a bug in Matomo. We are using on premise and cannot install any plugins.

Hope they release a patch soon.

[rafaelmaeuer]

This error occurs too when trying to generate an Authentication Token (token_auth) from UI: #18850

[timscha]

Have the same error, when I try to install the tag manager from the plugin overview.

[timscha]

With newest Version 4.8 I can finally install plugins again.

[tsteur]

I was able to reproduce a similar issue. There are race conditions in Matomo's session management that can cause data in the session (such as nonce entry) to go lost.