@Findus23 opened this Issue on February 21st 2020 Member

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)


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 https://github.com/matomo-org/matomo/issues/10578)
    (and this is where my guessing begins)
  • sometimes the system check takes quite some time due to the disk being slow (https://github.com/matomo-org/matomo/issues/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 commented on February 21st 2020 Member

integrity checker is skipped which takes a lot of time

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

@tsteur commented on February 21st 2020 Member

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 commented on February 22nd 2020 Member

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 commented on April 15th 2020 Member

@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 commented on April 15th 2020 Member

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.

@anoma commented on October 5th 2020

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 commented on October 5th 2020 Member

Yay, I'm not alone!

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

@asuckar commented on December 29th 2020

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 commented on January 6th 2021

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 commented on January 6th 2021

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

Powered by GitHub Issue Mirror