@dev-101 opened this Issue on June 21st 2019

Matomo 3.9.1

Today I decided to update one plugin that received an update recently, and when I navigated from a "Home" dashboard to Admin dashboard > Plugins and tried to click on Update button, error occurred and this error was generated in my log:

Error in Matomo: Could not verify the security token on this form., referer: /.../index.php?module=CorePluginsAdmin&action=plugins&idSite=1&period=range&date=last30&activated=

This URL seems very wrong to me, why would it contain date range (seems like a leftover from some of the pages I visited before)?

When I removed date range in the URL of the plugin update page so that it looked like this:

/.../index.php?module=CorePluginsAdmin&action=plugins&idSite=1

update went fine without issues, and I noticed token parameter was properly passed via get.

@tsteur commented on June 24th 2019 Member

Any chance you spent some time on the plugins page before updating? In theory the range date should be fine there but haven't tried to reproduce yet.

@dev-101 commented on June 24th 2019

No, it was immediate action.

@tsteur commented on June 24th 2019 Member

I've just tried to reproduce this in various ways and couldn't. Can you reproduce it @dev-101 ?

@dev-101 commented on June 24th 2019

Plugin SecurityInfo is now already updated to latest 3.0.7, I have changed the value in json manifest and database fields to lower version to trigger update availability again, but it still shows 3.0.7 in dashboard plugins list and nothing happens. I am not sure if there is some cache or cron cycle required. I'll wait and see if I can repeat the test.

@Findus23 commented on June 24th 2019 Member

I have also seen the error a few times when quickly updating some plugins. But I have no way to repoduce it and most of the time it works, so I never reported it.

@tsteur commented on June 24th 2019 Member

You could update in plugins/SecurityInfo/plugin.json the version number to 3.0.6 and also in the DB execute eg update matomo_options set option_value ='3.0.6' where option_name= 'version_SecurityInfo'

@tsteur commented on June 24th 2019 Member

It will then be possible to update again

@dev-101 commented on June 24th 2019

@tsteur Thanks, I missed that field.
Yes, the issue is triggered again :(

@tsteur commented on June 24th 2019 Member

How exactly do you update the plugin? Through the marketplace? The plugins page? If on the plugins page, through which button? Have you changed any configs?

@dev-101 commented on June 24th 2019

I update it through Admin dashboard as explained in opening post:

2019-06-24_140833

This is the only customization in my config, which is unrelated (and it doesn't work for what I want in changing available chart ranges, but that's not relevant now):

; maximum number of rows for any of the Referers tables (keywords, search engines, campaigns, etc.), and Custom variables names
; datatable_archiving_maximum_rows_referrers = 1000
; maximum number of rows for any of the Referers subtable (search engines by keyword, keyword by campaign, etc.), and Custom variables values
; datatable_archiving_maximum_rows_subtable_referrers = 500
; maximum number of rows for any of the Actions tables (pages, downloads, outlinks)
datatable_archiving_maximum_rows_actions = 3650
; maximum number of rows for pages in categories (sub pages, when clicking on the + for a page category)
; datatable_archiving_maximum_rows_subtable_actions = 500
; maximum number of rows for any of the Events tables (Categories, Actions, Names)
; datatable_archiving_maximum_rows_events = 500
; maximum number of rows for sub-tables of the Events tables (eg. for the subtables Categories>Actions or Categories>Names).
; datatable_archiving_maximum_rows_subtable_events = 100
; maximum number of rows for all individual Custom Dimensions reports, and for Custom Variables names report
; datatable_archiving_maximum_rows_custom_variables = 5000
; maximum number of rows for the Custom Dimensions subtables (list of all Page URLs per dimension value), and for Custom Variables values reports
; datatable_archiving_maximum_rows_subtable_custom_variables = 5000
@dev-101 commented on June 24th 2019

Here's the Update button link:

https:// ... /index.php?module=Marketplace&action=updatePlugin&idSite=1&period=range&date=last30&activated=&pluginName=SecurityInfo&nonce=ce1234b61cfb307227845r25f08329c0

And error page:

2019-06-24_141317

This is not an urgent bug or error, I have found workaround and plugin updates are not that frequent.

@dev-101 commented on June 24th 2019

I don't know how security tokens work, do you keep the value in sessions (which are now stored in database)? I mean, there was that famous issue with login and cookies, wonder if that fix could be related to this. Or maybe it is not.

@dev-101 commented on June 24th 2019

When I reload the update plugins page (so, I click first on the Plugins menu item in Administration (gear) section and then reload it again (on purpose)) and then click on Update button, it works.

It seems that token generated on first page load isn't synchronized properly, but works on second reload well.

@fdellwing commented on June 24th 2019 Contributor

I can confirm this problem.

2019/06/24 15:54:35 [error] 32371<a href='/32371'>#32371</a>: *2957284 FastCGI sent in stderr: "PHP message: Error in Matomo: Das Sicherheitstoken des Formulars konnte nicht verifiziert werden" while reading response header from upstream, client: 62.54.176.1, server: stats.promato.de, request: "GET /index.php?module=Marketplace&action=updatePlugin&idSite=2&period=day&date=today&activated=&pluginName=SecurityInfo&nonce=a3169d1ddf89d48dd896e7dbe1da1312 HTTP/1.1", upstream: "fastcgi://unix:/var/run/php/php7.2-fpm.sock:", host: "stats.promato.de", referrer: "https://stats.promato.de/index.php?module=CorePluginsAdmin&action=plugins&idSite=2&period=day&date=today&activated="
@tsteur commented on June 25th 2019 Member

Can't reproduce it unfortunately. Looking at the code it seems also straight forward. The token should be stored in the session which is stored in the DB and it is valid for a few minutes.

If someone who can reproduce this, can find out more, that would be great.

Are you using otherwise any Login plugins or third party plugins (plugins that are neither from Matomo nor from InnoCraft)?

@tsteur commented on June 25th 2019 Member

@mattab feel free to move the issue out of the milestone if we can't reproduce it by the time we're wanting to create a release

@dev-101 commented on June 25th 2019

Are you using otherwise any Login plugins or third party plugins (plugins that are neither from Matomo nor from InnoCraft)?

I only use AutoSetIgnore plugin that I made, it sets the ignore cookie for admin. I don't think it is related to tokens in any way. Other plugins are all official.

@mattab commented on June 26th 2019 Member

Updating plugins to latest version works for me in 3.10-rc release. Are you able to reproduce this consistently?

@dev-101 commented on June 26th 2019

Yes, apparently. I just noticed that updating is not the only affected operation.
Plugin Deactivate (uninstall) button is affected, too. I'll remove my plugin, just in case and repeat the tests, that's how I discovered this.

@dev-101 commented on June 26th 2019

Ok, when I deactivated my plugin, problem is gone on first click (activate, deactivate, uninstall).
However, when the page refreshes after the action, the value in the table still remains the same.
For example, if my button's action was the Deactivate function, plugin will be deactivated (2), but the table will still show it as active (1).

(1) Now, when I refresh (F5) the page again, it will be shown as inactive, as it should first time.

(2) Also, interesting part is this: if I do not refresh the page, and then click on e.g. Deactivate action button again, token message appears again and fails.

It seems to me that some kind of caching occurs internally in Matomo here, I just cannot explain why it manifests in different ways when my plugin is installed. Since I use platform initialized registered event, to trigger cookie set/refresh, it could be related somehow.

@fdellwing commented on June 26th 2019 Contributor

Updating plugins to latest version works for me in 3.10-rc release. Are you able to reproduce this consistently?

Could this be a problem that was fixed with 3.10? I do have this problem in 3.9.1.

Powered by GitHub Issue Mirror