@nkuehn opened this Issue on May 27th 2014


the HTML generated by the excellent Piwik email report generator contains References to the Piwik installation (e.g. some Icons and a Link to the Piwik installation).

On our HTTPS-Only accessible Piwik installation these URLs cannot be resolved because the URLs use the IP address of the Piwik instance instead of a valid hostname and the SSL certificate is only valid for the Hostname.

Should be resolvable easily because you have to configure the "Trusted Piwik Hostname" anyways in the Settings section (also for security reasons). I suppose the Path part of the Links is handled somehow (can't test that because my piwik is running in the root folder).

Keywords: email HTML

@mattab commented on May 30th 2014 Owner

@nkuehn thanks for report. What is the content of your config.ini.php | grep trusted_host ?

Is the hostname in the trusted_hosts?
Maybe the IP address is first in the list of trusted_hosts ?

@nkuehn commented on May 30th 2014


sure, could have included that in the first place. Heres's the setup:

  • runs "bare iron" (no virtual machines involved) on a host with the root IP (reverse DNS entry is not piwik, but the name we gave the physical machine as it runs other services, too)
  • accessed via a DNS name (piwik.excentos.com) that points to the same address (no second IP)
  • that IP is also the one that's written into the emails.
  • running in an PHP5-FPM pool behind nginx on the local machine.
    * less config.ini.php | grep trusted_hosts -> trusted_hosts[] = "piwik.excentos.com" (entered via conf settings page)

what looks bogus to me is the fact that the trusted_hosts value is not an array. But: it works (I don't get the "untrusted hostname" warning when logging in to the piwik interface)

@mattab commented on June 2nd 2014 Owner

Can you run SQL query and what is the result?

SELECT * FROM piwik_option WHERE option_name = 'piwikUrl';

@nkuehn commented on June 2nd 2014


mysql> SELECT * FROM piwik_option WHERE option_name = 'piwikUrl';
| option_name | option_value        | autoload |
| piwikUrl    | |        1 |
1 row in set (0.01 sec)

@mattab commented on June 5th 2014 Owner

See also

#5288 Sparklines fail to load behind reverse proxy because of wrong URI

#5290: Login leads to wrong URL when using ssl proxy

@nkuehn commented on June 5th 2014

Adding guesswork:

  • #5288 (sparklines path) may be related, but it seems to be just a path issue, not a root URL issue if I look at the screenshots)
  • #5290 sounds entirely different to me, that's about redirects after login.

I tried a search for "piwikUrl" in the github codebase, but couldn't see where the value is written into the database. I can imagine that the value is written at installation time (install wizard), but I installed this piwik installation directly on the real domain. (can't access it via IP adress because it's a name based server in nginx).

@nkuehn commented on June 10th 2014

argh, it gets even weirder: today in the early morning I received two "weekly" reports for the same website:

  • one for the week before the last week (05/26->06/01) with the correct URL including https in the paths to logo etc.
  • one for the last week (06/02->06/08) with the wrong URL (IP address).

The piwikUrl in the database is still the IP address.

Any ideas where to start researching?

@mattab commented on April 8th 2015 Owner

let's investigate this issue as part of the broader set of bugs in #6880 -> our goal will be to make Piwik work perfectly in this special use case which many users have reported issues with.

@mattab commented on September 14th 2017 Owner

Hi @nkuehn - do you still experience this issue in Piwik 3.1.0 ?

@nkuehn commented on September 19th 2017

Hi @mattab I am working in a different company for a while already and don't have an up to date setup available any more (and have no status and access to the one that we experienced this issue in). Sorry to say I can't help you out at the moment (don't have the spare private time any more too unfortunately).

If nobody else has come up with the issue since 2014 I personally would consider it irrelevant no matter if fixed or not.

But in any case I can recommend to test solely via an SSL-terminating reverse proxy and do not give the test runner direct access to the PHP IP / Host at all.

@krispii commented on October 2nd 2017

@mattab Are you forwarding from NGINX using localhost:someport?

I ask because we had this issue when I used proxy_pass http://localhost:someport but identifying the virtual host proxy_pass http://somepiwik.somedomain.tld:someport fixed the HTML email reports.

@nkuehn commented on October 2nd 2017

@krispii that could well be the reason but is a weird setup - you "hide" behind a reverse proxy to not make the internal URL / IP / Hostname accessible to the outside - proxying to the public external hostname is not the point of a proxy - you want to decouple internal deployment from external URL.

Powered by GitHub Issue Mirror