Running Nginx on Ubuntu, using the nginx config supplied here: https://github.com/matomo-org/matomo-nginx and no changes to the default matomo config.
After upgrading to 4.0.3, I am unable to log in to matomo receiving the error:
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.
It seems a number of users are experiencing this bug after visiting the bugs section of the user forums.
Could you check if https://forum.matomo.org/t/cant-sign-in-on-my-own-servers-matomo/39537/4?u=lukas applies for you.
Some other people reported it also here:
The condition of "Nginx and are using multiple domains, for example (matomo.onesite.example and matomo.anothersite.example)" does not apply in our case.
I've reviewed and contributed to both of those posts before submitting this bug.
@psec not sure if you say the recent comment in the forum. Does it maybe help to clear cookies? Any chance you are accessing your Matomo with HTTP instead of HTTPS? OR maybe there is a redirect somehow to a different domain on log in?
You could temporarily also try setting in the
[General] section this config setting:
enable_trusted_host_check=0 and then try to log in again. That's in your
config/config.ini.php file. Be great to know if that helps.
@tsteur yes, clearing cookies and cache was the first thing that was tested. Have tried a number of edits listed in the various posts in the user forum to config.ini.php including the above without success. No, I am not trying to access over HTTP instead of HTTPS.
Guys, nothing has changed on my end except the 4.0.3 update. I had zero issues before applying this update. I do appreciate the suggested workarounds but this is a regression and should be treated as such.
@psec we are treating it as such but we need to find out what helps/what causes it as it's not clear just yet unfortunately. If you could maybe try that other config setting that would help too. We're not understanding yet what is causing it and we can't reproduce it ourselves.
I had the same problem. For me the problem was that I was using two different domains to access Matomo, even though it worked perfectly before the upgrade to 4.0.3 from version 3. I fixed it by removing the second domain from my nginx configs and from the
config/config.ini.php. With that I was able to log back in.
This sounds a lot like what I described in https://forum.matomo.org/t/cant-sign-in-on-my-own-servers-matomo/39537/4?u=lukas
Just updated to matomo 4.0.4 . I also use Nginx. Login is not longer possible. Same issue as above.
@Findus23 workaround works, but why not use $_SERVER['HTTP_HOST'] as fallback?
The web has 2 domains example.com and www.example.com and everything is redirected to www. SERVER_NAME is without www and the added trusted host won't work/fix it. I had www.example.com in trustedHosts and added example.com in a new line as well in array syntax.
The change had no impact and i still need to change the server_name to the host name.
I don't have two domains. I use Nginx with Apache. Matomo sees my hostname as
"_" instead of its IP address as it used to do before the update to 4.0.4 from 3.14. I added "_" to trusted hosts and then I get the above message with Form security failed.
I had the same problem on my dev machine. I use the following url: https://mylocalurl:8080
When I try to login, I get the same error msg, because the $origins array doesn't contain mylocalurl
with port 8080
that logic was already updated in 3.14.0
@psec or someone else reading this to do you remember from what Matomo version you updated to Matomo 4?
Any chance you have the
[General]force_ssl=1 setting enabled in
I was on the latest stable v3 before i updated. No suggested updates the last weeks.
This was always enabled
So far one thing I noticed while debugging:
Then because the host is not valid in Url::getHost it falls back to SERVER_ADDR because the host is not valid (config file only includes trusted_host=8123). As a result it redirects me to
SERVER_ADDR which is 127.0.0.1.
This is one change because there's usually maybe in Matomo 3 the port would have bit ignored maybe. It might be the same though and this should be unrelated to this issue.
On HTTP only I get an error when setting the initial session cookie (so it later doesn't even have an nonce value to compare with )
because I was using HTTP and it would have overwritten my cookie on
I then went to example.com and cleared my cookies there. Then it was correctly setting the session cookie.
Then I tried logging in. My origin was
http://example:8123. The current host was
apache.matomo:8123 and I could log in. However, I think if I hadn't set the correct
trusted_host with the port I would not have been able to log in.
Just wanted to post this so far.
It looks like there are 2 issues for people re
SERVER_NAME and then the port.
@tricsusz could you check in your
config/config.ini.php file what is configured as
trusted_hosts? It can also be checked in the UI by going to Admin -> General Settings. There should be a section for trusted hosts. Is the host with the port whitelisted there?
This should hopefully be fixed with #16899. Please let us know if the issue still occurs in Matomo 4.0.5
I can confirm that after manually adding your changes to my files and using the following settings in config.ini.php:
assume_secure_protocol=0 host_validation_use_server_name = 0 enable_trusted_host_check=0
I was able to login.
Hi @Bllacky can you also log in when
enable_trusted_host_check=1 I reckon this should be expected to work by now. Unless you had it already disabled before the Matomo 4 update?
I did the manual merge so I could log in and do the update to matomo 4.0.5 from the matomo.
Now I am on Matomo 4.0.5.
I tried with enable_trusted_host_check=1 and it works with it as well.
Great, thanks for testing and confirming @Bllacky
No problem! It's the least I could do given all your hard work on this.
I am able to log in now after updating to 4.0.5. Appreciate your attention to this issue! I will close this bug.