Can't sign in on My own server's matomo

Support & Bugs
#1

Error: Form security failed. Please reload the form and check that your cookies are enabled. If you use a proxy server, you must configure Matomo to accept the proxy header that forwards the Host header. Also, check that your Referrer header is sent correctly.

I tried every forum post related to this. I can sign in from matomo mobile 2 though

#2

Hi,

Are you using Nginx?

#3

@Lukas is there a known solution to this bug when using Nginx? Clearly a number of people are having this issue and this is an obvious regression. Linking any known solution would be appreciated.

#4

Hi,

The one issue I know is that if you are using Nginx and are using multiple domains for your Matomo instance (like matomo.onesite.example and matomo.anothersite.example) then the login might fail on the secondary domains.

This is because by default nginx sets the SERVER_NAME variable it passes to PHP to the host of the first entry in the server_name list. But Matomo uses this variable for a host check and if it doesn’t match (which happens on the secondary domain), the login fails.

One solution for this is to add

fastcgi_param  SERVER_NAME        $host;

directly before the

fastcgi_pass unix:/var/run/php/php7.3-fpm.sock;

line. (so after any snippets/fastcgi-php.conf line)

Locked out of Matomo - Again
#5

I am also on Nginx and that did not help me. And this is a brand new problem on an upgrade to 4.0.3 from 3.14.1 and after running all database updates (and truncating the session table, after I observed the problem).

But Matomo uses this variable for a host check and if it doesn’t match

What is the check being done against? Is it a value in the database?

EDIT:
in the end I did:

  1. an update to the piwik_option table as the piwikUrl was set to an older domain (which we have been redirecting away with a 301 to a newer domain for a long time, as well as both domains being in the config.ini.php as trusted_hosts[] entries, and this was never an issue til now to login with the newer domain)
  2. peppered my nginx vhost with fastcgi_param SERVER_NAME $host; both before and after the fastcgi_pass… maybe ordering mattered. My snippet was like this:
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php7.2-fpm.sock;
    }

The fastcgi_param SERVER_NAME is also set in a file that is included via snippets/fastcgi-php.conf so it was possibly overriding the setting I had set. I put the SERVER_NAME param both before and after to be sure.

So in the end, this indeed worked (the fastcgi_param SERVER_NAME statement has to be the last case so it doesn’t get overridden, or if it suits your setup and doesn’t break other sites on the server that depend on the include file, then edit wherever it is already being set in the include file…):

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_param  SERVER_NAME        $host;
        fastcgi_pass unix:/run/php/php7.2-fpm.sock;
    }

Truncating the session table was probably not necessary but was done for good measure…