@ToBeReplaced opened this Issue on November 11th 2014

If you use a reverse proxy to host Piwik at https://www.example.com/analytics/index.php, piwik will attempt to request https://www.example.com/plugins/Morpheus/images/logo.svg. Similarly, when you log in, it will redirect to https://www.example.com/index.php.

Is there a way to specify a url prefix for redirects (ex. the 302 after log-in?).

Other than the logo.svg, other assets appear to resolve properly.

Right now, this is solvable with rewrites from the proxy, so it's not a priority.

@mattab commented on December 1st 2014 Member

Hi @ToBeReplaced thanks for the report. Do you also experience this issue: #6703 ?

@ToBeReplaced commented on December 9th 2014

The real-time map fails to work. However, I do not experience the same issue:

I see a failed request to https://www.example.com/plugins/UserCountryMap/svg/world.svg, which should be https://www.example.com/analytics/plugins/... in my case.

Sorry for the delay.

@Hubro commented on March 4th 2015

I am also experiencing this issue. When logging into Piwik using the URL:


I am redirected to:


Which is causing some confusion and annoyance. When I press Back I am taken to the dashboard.

@mattab commented on April 8th 2015 Member

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.

@patriiiiiiiiiick commented on June 8th 2015

@ToBeReplaced Could you please document the rewrite you've used? Thanks in advance!

@ToBeReplaced commented on June 8th 2015

@patriiiiiiiiiick This is an extract of my nginx.conf. This is inside of a docker container that has host piwik mapped to another instance of nginx serving piwik on port 80. The configuration redirects all traffic to use TLS, but it communicates with piwik in the clear.

location = /analytics/index.php {
  limit_except GET POST {}
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Host $host;
  proxy_set_header Host $host;
  proxy_redirect https://www.example.com/index.php /analytics/index.php;
  proxy_pass http://piwik/index.php;}

location /analytics/ {
  limit_except GET POST {}
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Host $host;
  proxy_set_header Host $host;
  proxy_pass http://piwik/;}}}

In the piwik host:

location = / {
  return 301 https://www.example.com/analytics/index.php;}

location ~ [^/]\.php(/|$) {
  fastcgi_split_path_info ^(.+?\.php)(/.*)$;
  if (!-f $document_root$fastcgi_script_name) {
    return 404;}
  fastcgi_pass php:9000;
  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  include /etc/nginx/fastcgi_params;}}}
@mattab commented on November 2nd 2015 Member

can you let us know the content of PHP $_SERVER? We kinda need it in order to fix this issue.

To get it, can you create a file like test.php in your Piwik directory and paste



afterwards you can open this file by opening the URL https://yourdomain/test.php in the browser. Please remove this file afterwards again

@ToBeReplaced commented on November 2nd 2015

I placed test.php and then requested https://www.example.com/analytics/test.php.

array (
  'USER' => 'apache',
  'HOME' => '/usr/share/httpd',
  'SCRIPT_FILENAME' => '/etc/nginx/html/test.php',
  'QUERY_STRING' => '',
  'CONTENT_TYPE' => '',
  'SCRIPT_NAME' => '/test.php',
  'REQUEST_URI' => '/test.php',
  'DOCUMENT_URI' => '/test.php',
  'DOCUMENT_ROOT' => '/etc/nginx/html',
  'SERVER_SOFTWARE' => 'nginx/1.7.7',
  'REMOTE_ADDR' => scrubbed,
  'REMOTE_PORT' => '59901',
  'SERVER_ADDR' => scrubbed,
  'SERVER_PORT' => 80,
  'SERVER_NAME' => 'www.example.com',
  'REDIRECT_STATUS' => '200',
  'HTTP_X_FORWARDED_FOR' => scrubbed,
  'HTTP_X_FORWARDED_HOST' => 'www.example.com',
  'HTTP_HOST' => 'www.example.com',
  'HTTP_CONNECTION' => 'close',
  'HTTP_USER_AGENT' => 'curl/7.43.0',
  'HTTP_ACCEPT' => '*/*',
  'PHP_SELF' => '/test.php',
  'REQUEST_TIME_FLOAT' => 1446437222.2988,
  'REQUEST_TIME' => 1446437222

This is after my fancy rewrites as indicated above though, so it might not be particularly helpful. Notably, the "analytics" prefix is nowhere to be seen.

I don't know what you are planning, but for me, it would be great to specify a "url_prefix" in config.ini.php that defaults to /. While I can use the proxy server to perform rewrites on 3xx redirects, I can't use that to rewrite assets that are appearing in Piwik's html, like the logo.svg.

I might also be misunderstanding altogether now; This was a while back, and I haven't touched my installation since I first spun it up -- almost a year now!

@Zougi commented on May 19th 2016

I've got the exact same issue

@fhadlich commented on January 15th 2017

Issue still exists, most likely because SettingPiwik::getPiwikUrl (with the help of URL::getCurrentScriptName) determines the URL wrong. There is even a DB option for "piwikUrl", but manually setting it to the correct URL is being overwritten immediately upon next request.
I wonder why there is no chance of explicitly setting the URL for a use case as demonstrated by @ToBeReplaced. I'm about to run a similar set-up (nginx reverse proxy) and have to look for workarounds now :-(

Edit, got one workaround to work successfully: Move Piwik in subfolder named identically to the path the reverse proxy is using, i.e. to /path/to/wwwroot/analytics/ instead of /path/to/wwwroot/.

nginx vhost conf of reverse proxy:

``` location /analytics/ { ... proxy_pass http://:8081/analytics/; ... } ``` nginx vhost conf for piwik: ``` root /path/to/wwwroot/; ... location /analytics/ { ... try_files $uri /analytics/index.php?$query_string; } ```
@mattab commented on February 18th 2017 Member

Thanks for posting your workaround @fhadlich

@benjaminpesch commented on March 23rd 2017

I could resolve the issue by patching the core/Url.php
The function getCurrentScriptName has an option to remove the PathInfo, which is set by default.
If $_SERVER['PATH_INFO'] is set but empty, the complete path is stripped off, which is wrong.

if ($removePathInfo && isset($_SERVER['PATH_INFO']) ) {
   $url = substr($url, 0, -strlen($_SERVER['PATH_INFO']));

I fixed it with an additional check:

if ($removePathInfo && isset($_SERVER['PATH_INFO']) && !empty($_SERVER['PATH_INFO'])) {
    $url = substr($url, 0, -strlen($_SERVER['PATH_INFO']));
@mattab commented on September 14th 2017 Member

a new pull request was submitted by @user121216 in https://github.com/piwik/piwik/pull/12011 and addresses this issue (by adding a new nginx setting for proxy_set_header X-Forwarded-Uri /subfolder_here; if you could test and leave a comment on the PR that would be great.

@ToBeReplaced commented on September 15th 2017

@mattab Thank you for the callback on this. I am unfortunately not in a position to test the PR. Hopefully another affected user will be able to chime in.

@patriiiiiiiiiick commented on September 15th 2017

I can't locate/reproduce this issue now (I can't remember if we applied some of the workarounds above) and can't justify having it tested as the concerned instance is in phase out. I'll notify other people in case they can give it a try.

@mattab commented on November 19th 2017 Member

Hi everyone,

Since #12011 was merged, we consider this issue fixed. Please check the FAQ here for more information: https://piwik.org/faq/how-to-install/faq_98/

in particular check the section If Piwik is behind a reverse proxy and installed in a sub-path

Feedback welcome!

@PotcFdk commented on January 13th 2018

@mattab Can you look into the issue that @benjaminpesch posted about?
I don't have piwik/matomo behind a reverse proxy, but instead I'm rewriting the requests. Everything works correctly... well. Almost. Some paths and the logo are broken. The piwik.piwik_url is pointing to the on-disk directory name, not the one that is visible from the public.
(i.e., it's installed in /var/www/local-dir, whereas it's accessed via https://example.org/public-dir; the logo points to https://example.org/local-dir/..., which is wrong)

As @benjaminpesch pointed out, there is this code in Version 3.3.0:

if ($removePathInfo && isset($_SERVER['PATH_INFO']) ) {
   $url = substr($url, 0, -strlen($_SERVER['PATH_INFO']));

Before the if line, $url points to the public-dir, but then $url = substr($url, 0, -strlen($_SERVER['PATH_INFO'])); runs:
PATH_INFO is empty for me, so it results in substr($url, 0, 0). This results in $url getting cleared, so it's empty afterwards, and then it falls back to what comes below that code:

         * SCRIPT_NAME is our fallback, though it may not be set correctly
         * <a class='mention' href='https://github.com/see'>@see</a> http://php.net/manual/en/reserved.variables.php
        if (empty($url)) {
            if (isset($_SERVER['SCRIPT_NAME'])) {
                $url = $_SERVER['SCRIPT_NAME'];
            } elseif (isset($_SERVER['SCRIPT_FILENAME'])) {
                $url = $_SERVER['SCRIPT_FILENAME'];
            } elseif (isset($_SERVER['argv'])) {
                $url = $_SERVER['argv'][0];

tl;dr: PATH_INFO is empty -> $url gets cleared -> $url is filled with a fallback path (inaccessible from the public) -> logo breaks, piwik.piwik_url has wrong value
This was not touched by #12011 and is still broken

@mattab commented on January 23rd 2018 Member

Thanks @PotcFdk and @benjaminpesch for reporting this issue! I've opened this PR to address it: https://github.com/matomo-org/matomo/pull/12500
-> could you please test this small patch on your instance, and report on the PR if it's working for you? Thanks

This Issue was closed on November 19th 2017
Powered by GitHub Issue Mirror