Does not work for none of the accounts. Both domain types (with and without www) are included in config.inc.php as trusted_hosts[]. By standard we have a routing included on www by htaccess. All are on SSL. But that shouldn’t be the problem. Any other ideas?
Matomo is installed in a subdirectory.
Thanks, Daniel. Login from https://domain.com does work.
Even though www.domain.com is declared as a trusted host in the config.ini.php, login through www doesn’t work.
@Lukas, Matomo is in a subdir, and it is accessed over https.
1 Like
Hi,
Could you maybe also tell us which exact package you are using at 1&1?
I am assuming you are referring to www.ionos.de, right?
Having same problem, also ionos managed server (Dedicated Server QC L Website). I had Internal Server Error during update and now I’m locked out as others described above. I also run two other instances on a “Dedicated Server DC M Website” that work fine after update. I guess something went wrong in some updates.
Updated to latest version and also can’t log in anymore and using 1&1, just the basic hosting package with SSL. First after install it told me to add trusted host without www. did that and it now goes to log in page but get the error like others. Tried everything listed here.
EDIT: Just did a fresh install of 4.04 with new database and still can’t log in.
@Lukas To sum up my configuration:
- Everything hosted at Ionos-1and1 on a shared host somewhere (can’t really locate the servers, right now it is a subdomain of clienthosting.eu)
- protocol in use is https (with .htaccess forcing to https)
- MySQL: 5.5.60-0+deb7u1-log
- PHP: 7.4.13
- Matomo (4.0.4) stored in a subdirectory
- no specific package used (it is a direct install out of the box)
- specific values in config.ini: force_ssl=1 + salt value + trusted host (‘mydomain.com’ + ‘www.mydomain.com’)
- system check unhappy with the value of ‘max_allowed_packet’ (16Mb) but I’m afraid I can’t change that
Let me know if you need additional info from my configuration.
With that, I can login through ‘mydomain.com’ but not through ‘www.mydomain.com’.
That’s enough to me, but still sounds like it is not what it should be.
Thanks.
I was able to resolve the form-security error by updating my nginx configuration. I’m working with a Synology server, so your configuration files will be different, but the concept is easily adaptable. In Synology, they use a catch-all server_name value of “_”. Matomo is confused by that, and tries handing it as a proxied connection. The trick is to pass the actual server hostname to Matomo via a PHP variable.
One line (fastcgi_param, below) was added to this config file: /etc/nginx/conf.d/www.Piwik.conf
After editing the conf file, test the config for errors (nginx -t) and then reload it (synoservicectl --reload nginx).
location ~* ^/piwik/(?:index|piwik|js\/index).php$ {
include fastcgi.conf;
fastcgi_pass unix:/run/php-fpm/php72-fpm.sock;
fastcgi_param SERVER_NAME $host;
fastcgi_read_timeout 3600;
}
Hi everyone,
For all who are still having this issue:
Could you please check the content of $_SERVER['HTTP_ORIGIN'] on your server and if matches the current host or if it maybe contains the port number additionally?
The easiest way to do so is to create a test.php file in the Matomo directory with
<?php
var_dump($_SERVER['HTTP_ORIGIN']);
For reference $_SERVER['SERVER_NAME'] and $_SERVER['HOST'] might also be interesting.
HOST = www.mydomain.com (no port)
SERVER_NAME = mydomain.com (no port)
I can’t get HTTP_ORIGIN to output anything (it keeps sending a NULL value).
1 Like
HTTP_ORIGIN = NULL
SERVER_NAME = string(xx) “(subdomain).mydomain.com”
HOST = NULL
Same on working and none working instances. Working ones are accessed with subdomain, none working is in subdirectory.
Login without “www” also doesn’t work for me. But then I get different error. It says username and password isn’t correct.
I remembered my none working instance also was accessed with subdomain in the past. The subdomain still exists. Login was possible immediatly.
So it seems to be a subdirectory problem.
Hi everyone,
anyone on 1&1 hosting, could you let me know what package you have? I’d then subscribe to the same plan and would try to reproduce it. Is that 1&1 Germany or some other country? Be great to know so we can try & reproduce & fix this issue 
Same problem here. My domain is also registered with 1&1 (IONOS) but hosted elsewhere on a VPS. I’m also using Cloudflare.
HTTP_ORIGIN = NULL
SERVER_NAME = example.com
HOST = NULL
HTTP_HOST = www.example.com
The solution suggested by Aaron Stephens did not work for me.
EDIT: Ah, actually it did work, I just had to put this line after including the default fastcgi_params. Thanks Aaron!
Basically I guess what is happening is that I have two server names in my nginx config
server {
server_name example.com www.example.com
...
}
and the $server_name variable is always set to the first one even when I access the website through www.example.com. Matomo looks at the SERVER_NAME variable when checking validity of the host (see https://github.com/matomo-org/matomo/blob/06d43857c48ada2fa7f1ad18a8309e8826c0e413/core/Url.php#L201) and this is by default set to $server_name of course by nginx. If we reset the value of SERVER_NAME to $host, this solves the problem.
Hi everyone,
In the next few days Matomo 4.0.5 should come out which should fix this issue for everyone and also not require the nginx change anymore:
If you can’t wait, you could in the meantime try applying these changes to your Matomo instance:
Hi Thomas,
Sorry for the late reply. If that’s still of use: my 1and1 contract is a basic plan called “1&1 Unlimited Plus”. It is a French contract but the servers I hit seem to be located in DE.
Hi Thomas, this problem appears on different clients packages at 1&1 Germany. One is with the package “Pro” and the others with “Business”. Hope that late answer helps.
Output:
NULL string(13) “domain.de” NULL
Hi everyone. We have released Matomo 4.0.5 which hopefully fixes all the issues. Be great if someone could test and confirm this Thanks for your help and patience. Very much appreciated
4 Likes
Thank you guys, we will check)
Hi Thomas,
Yes, 4.0.5 seems to have fixed the issue. At least on my end. Thanks for the quick fix!
1 Like