@jochen42 opened this issue on October 21st 2014

Hi,

while automatic update to 2.8.1, the browser got too many redirects. Now a can not login into piwik. But the tracking seems to work.

In the webserver log i only see this redirects while trying to open index.php:

17.51.3.20 - - [21/Oct/2014:12:40:32 +0200] "GET /index.php HTTP/1.1" 302 5 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Firefox/33.0" 217.51.3.20 - - [21/Oct/2014:12:40:32 +0200] "GET /index.php HTTP/1.1" 302 5 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Firefox/33.0" 217.51.3.20 - - [21/Oct/2014:12:40:32 +0200] "GET /index.php HTTP/1.1" 302 5 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Firefox/33.0" 217.51.3.20 - - [21/Oct/2014:12:40:32 +0200] "GET /index.php HTTP/1.1" 302 5 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Firefox/33.0" 217.51.3.20 - - [21/Oct/2014:12:40:32 +0200] "GET /index.php HTTP/1.1" 302 5 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Firefox/33.0" 217.51.3.20 - - [21/Oct/2014:12:40:32 +0200] "GET /index.php HTTP/1.1" 302 5 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Firefox/33.0"

an aditional information: the archive-cron-job was running while updating. perhaps this is the problem.

in my local test installation everything worked fine.

i am using php 5.5.9, with php-fpm.

@jochen42 commented on October 21st 2014

a manual clean install of 2.8.0 get it back working. a manual clean install of 2.8.1 did not.

@mnapoli commented on October 21st 2014

Hi,

Are you using Nginx or Apache? Is Piwik installed at the root (i.e. http://example.com/index.php) or in a subdirectory (i.e. http://example.com/subdirectory/index.php) ?

@jochen42 commented on October 21st 2014

hi mnapoli.

i am using nginx and piwik is installed in the root.

thx, jochen

@mnapoli commented on October 21st 2014

Thanks. If it is possible for you, we could use some help debugging it. We are running tests with nginx and php-fpm too and they are passing. If you could provide use with the content of the $_SERVER variable that could help a lot to reproduce it, fix it and add it to out test suite.

A way to do that is to edit Piwik's source code on the web server. If you are comfortable doing this, then create a new file named test.php at the root of Piwik's source code (where index.php is). Add this code in the file:

<?php
var_dump($_SERVER);

Now if you visit http://you-domain.com/test.php you should see a lot of information. Could you copy the data here? Take care to remove all sensitive information, like the server name, cookie data or directories for example.

Remember to remove the test.php file once finished.

@jochen42 commented on October 21st 2014

hey. you are welcome!

here is the content of $_SERVER:

array(32) {
  ["USER"]=>
  string(9) "www-piwik"
  ["HOME"]=>
  string(26) "/sites/<some folder>"
  ["FCGI_ROLE"]=>
  string(9) "RESPONDER"
  ["QUERY_STRING"]=>
  string(0) ""
  ["REQUEST_METHOD"]=>
  string(3) "GET"
  ["CONTENT_TYPE"]=>
  string(0) ""
  ["CONTENT_LENGTH"]=>
  string(0) ""
  ["PATH_INFO"]=>
  string(18) "/___server_var.php"
  ["SCRIPT_FILENAME"]=>
  string(51) "/sites/<some folder>/htdocs/___server_var.php"
  ["SCRIPT_NAME"]=>
  string(18) "/___server_var.php"
  ["REQUEST_URI"]=>
  string(18) "/___server_var.php"
  ["DOCUMENT_URI"]=>
  string(18) "/___server_var.php"
  ["DOCUMENT_ROOT"]=>
  string(33) "/sites/<some folder>/htdocs"
  ["SERVER_PROTOCOL"]=>
  string(8) "HTTP/1.1"
  ["GATEWAY_INTERFACE"]=>
  string(7) "CGI/1.1"
  ["SERVER_SOFTWARE"]=>
  string(11) "nginx/1.4.6"
  ["REMOTE_ADDR"]=>
  string(11) "<ip>"
  ["REMOTE_PORT"]=>
  string(5) "61404"
  ["SERVER_ADDR"]=>
  string(10) "<ip>"
  ["SERVER_PORT"]=>
  string(2) "80"
  ["SERVER_NAME"]=>
  string(19) "<some domain>"
  ["REDIRECT_STATUS"]=>
  string(3) "200"
  ["HTTP_HOST"]=>
  string(19) "<some host>"
  ["HTTP_USER_AGENT"]=>
  string(81) "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Firefox/33.0"
  ["HTTP_ACCEPT"]=>
  string(63) "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"
  ["HTTP_ACCEPT_LANGUAGE"]=>
  string(23) "de,en-US;q=0.7,en;q=0.3"
  ["HTTP_ACCEPT_ENCODING"]=>
  string(13) "gzip, deflate"
  ["HTTP_COOKIE"]=>
  string(178) "..."
  ["HTTP_CONNECTION"]=>
  string(10) "keep-alive"
  ["PHP_SELF"]=>
  string(36) "/___server_var.php/___server_var.php"
  ["REQUEST_TIME_FLOAT"]=>
  float(1413929141.27)
  ["REQUEST_TIME"]=>
  int(1413929141)
}

thank you for the help!

@jochen42 commented on October 21st 2014

i needed to cleanup the array, because there was to much info's for potential attacks...

@mnapoli commented on October 21st 2014

Thanks! I've removed all the cookie data just to be sure, I don't need them. I've also removed any IP address.

So there's indeed something that looks weird here: ___server_var.php everywhere instead of test.php. Does it ring a bell to you? Is that in your Nginx config?

@jochen42 commented on October 21st 2014

no. it is "___server_var.php" instead of "test.php" as you suggested. the nginx config is extremly simple:

        location ~ \.php$ {
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                fastcgi_pass unix:/var/run/php5-fpm-piwik.sock;
                fastcgi_index index.php;
        fastcgi_read_timeout 300;
                include fastcgi_params;
        }

no rewrite or something...

@mnapoli commented on October 21st 2014

OK so __server_var.php is your script then. I'm looking into it.

@voku commented on October 21st 2014

when I revert this commit https://github.com/piwik/piwik/commit/2aae308d66cbf2d54bdff95ca5a7f25e7b964279 || when I try https everything is working again

$url = Url::getCurrentScheme() . '://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI']; var_dump($url); var_dump(Url::getCurrentUrl()); exit();

string(107) "http://suckup.de/piwik/index.php?module=UsersManager&action=userSettings&idSite=1&period=day&date=yesterday" string(123) "http://suckup.de/piwik/index.php/piwik/index.php?module=UsersManager&action=userSettings&idSite=1&period=day&date=yesterday"

@mnapoli commented on October 21st 2014

Do you know the value of the cgi.fix_pathinfo configuration in your php.ini (maybe in /etc/php/php-fpm/php.ini)? It should be 1 according to the Nginx documentation.

All seems correct except for PATH_INFO (which should be empty) and PHP_SELF which should be /___server_var.php instead of /___server_var.php/___server_var.php.

Because of these values, Piwik thinks the current URL is /___server_var.php/___server_var.php and so it redirects to /___server_var.php.

@voku Yep it makes sense. When you revert, it doesn't use the "wrong" global variables anymore.

I'm trying to understand why those global variables are set wrong :/

@jochen42 commented on October 21st 2014

in my case it doesnt matter if http oder https. but i will test this tomorow...

@jochen42 commented on October 21st 2014

fix_pathinfo was 1. i just tried to set it to 0, the PHP_SELF seems to be correct. this is totaly different to the last sentence of that nginx-documentation. wiered.

a also tested to upgrade with fix_pathinfo=0 and the following $_SERVER and the same result (redirect error).

array(32) {
  ["USER"]=>
  string(9) "www-piwik"
  ["HOME"]=>
  string(26) "/sites/<some folder>"
  ["FCGI_ROLE"]=>
  string(9) "RESPONDER"
  ["QUERY_STRING"]=>
  string(0) ""
  ["REQUEST_METHOD"]=>
  string(3) "GET"
  ["CONTENT_TYPE"]=>
  string(0) ""
  ["CONTENT_LENGTH"]=>
  string(0) ""
  ["PATH_INFO"]=>
  string(18) "/___server_var.php"
  ["SCRIPT_FILENAME"]=>
  string(51) "/sites/<some folder>/htdocs/___server_var.php"
  ["SCRIPT_NAME"]=>
  string(18) "/___server_var.php"
  ["REQUEST_URI"]=>
  string(18) "/___server_var.php"
  ["DOCUMENT_URI"]=>
  string(18) "/___server_var.php"
  ["DOCUMENT_ROOT"]=>
  string(33) "/sites/<some folder>/htdocs"
  ["SERVER_PROTOCOL"]=>
  string(8) "HTTP/1.1"
  ["GATEWAY_INTERFACE"]=>
  string(7) "CGI/1.1"
  ["SERVER_SOFTWARE"]=>
  string(11) "nginx/1.4.6"
  ["REMOTE_ADDR"]=>
  string(11) "<some ip>"
  ["REMOTE_PORT"]=>
  string(5) "63245"
  ["SERVER_ADDR"]=>
  string(10) "<some ip>"
  ["SERVER_PORT"]=>
  string(2) "80"
  ["SERVER_NAME"]=>
  string(19) "<some server name>"
  ["REDIRECT_STATUS"]=>
  string(3) "200"
  ["HTTP_HOST"]=>
  string(19) "<some host>"
  ["HTTP_ACCEPT"]=>
  string(63) "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"
  ["HTTP_COOKIE"]=>
  string(188) "<cleaned>"
  ["HTTP_USER_AGENT"]=>
  string(116) "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/600.1.17 (KHTML, like Gecko) Version/7.1 Safari/537.85.10"
  ["HTTP_ACCEPT_LANGUAGE"]=>
  string(5) "de-de"
  ["HTTP_ACCEPT_ENCODING"]=>
  string(13) "gzip, deflate"
  ["HTTP_CONNECTION"]=>
  string(10) "keep-alive"
  ["PHP_SELF"]=>
  string(18) "/___server_var.php"
  ["REQUEST_TIME_FLOAT"]=>
  float(1413934457.297)
  ["REQUEST_TIME"]=>
  int(1413934457)
}
@jochen42 commented on October 21st 2014

the php documentation also says, that 1 is the new "correct" settings for fix_pathinfo.

but i saw now, that in the nginx documentation i schould also add

fastcgi_split_path_info ^(.+?\.php)(/.*)$;

i will test this now.

@voku commented on October 21st 2014

here is a example config -> http://wiki.nginx.org/PHPFcgiExample

@jochen42 commented on October 21st 2014

OK i am sorry. it isn't a piwik bug. in nginx the folowing lines was missing:

fastcgi_param   PATH_INFO               $fastcgi_path_info;
fastcgi_param   PATH_TRANSLATED     $document_root$fastcgi_path_info;

THX for your help

@jochen42 commented on October 21st 2014

now everything works fine.

@mnapoli commented on October 22nd 2014

From the forums:

I can confirm that the following addition worked (php 5.4, nginx, php fpm):

/etc/nginx/fastcgi_params

fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info;

@mnapoli commented on October 22nd 2014

@jochen42 & @voku Were you using https://github.com/perusio/piwik-nginx?

BTW I have pushed a fix to master.

Basically what happened in the Url class: - getPathInfo() was returning PATH_INFO - getScriptName() was returning the URI minus PATH_INFO - getCurrentUrl() was returning host + getScriptName() + getPathInfo()

The bug is when Nginx provides an incorrect PATH_INFO (as diagnosed here, it can happen when it is misconfigured) then host + getScriptName() + getPathInfo() messes up and returns a wrong URL.

What I did is I removed getPathInfo() (was used only for getCurrentUrl()). Now: - getScriptName() returns the URI minus PATH_INFO and getScriptName(false) returns the URI - getCurrentUrl() returns host + getScriptName(false)

So instead of stripping PATH_INFO to re-add it in getCurrentUrl(), it is never stripped. That way we never use PATH_INFO so everything should be OK.

The commit is here: https://github.com/piwik/piwik/commit/ad2c051089281bbfa39b9426e1009a7a2fb9d08d

@noa-appletech commented on October 22nd 2014

Hello, I am running as a virtual server under Nginx 1.6.2 on CentOS 6.5 and I am having the same problem after upgrading to Piwik v2.8.1.

Things were running smoothly until now with the following config:

server {

    listen [::]:80;

    server_name  ...;
    access_log  /var/.../.../log/access_log main;
    error_log /var/.../.../log/error_log warn;
    root   /var/.../.../www/;

    index  index.php index.html index.htm index.cgi default.html default.htm default.php;

    location / {
       try_files $uri $uri/ /index.php?$args;
       allow 127.0.0.1;
       allow ::1;
       allow 10.10.10.0/24;
       deny all;  
    }

    location ~ \.php$ {

       allow 127.0.0.1;
       allow ::1;
       allow 10.10.10.0/24;
       deny all;
       fastcgi_cache off;

       try_files $uri =404;
       include /etc/nginx/fastcgi_params;

       fastcgi_param PATH_INFO $fastcgi_script_name;

        fastcgi_intercept_errors on;

        fastcgi_buffer_size 384k;
        fastcgi_buffers 256 16k;
        fastcgi_busy_buffers_size 384k;
        fastcgi_temp_file_write_size 384k;
        fastcgi_read_timeout 5h;

        fastcgi_pass unix:/tmp/php-fpm.sock;

        fastcgi_index index.php;

        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;       
    }
}

I did a server var dump as advised earlier in this thread with the following output:

array(34) {
  ["FCGI_ROLE"]=>
  string(9) "RESPONDER"
  ["QUERY_STRING"]=>
  string(0) ""
  ["REQUEST_METHOD"]=>
  string(3) "GET"
  ["SCRIPT_NAME"]=>
  string(15) "/myverytest.php"
  ["REQUEST_URI"]=>
  string(15) "/myverytest.php"
  ["DOCUMENT_URI"]=>
  string(15) "/myverytest.php"
  ["DOCUMENT_ROOT"]=>
  string(22) "/var/.../.../www"
  ["SERVER_PROTOCOL"]=>
  string(8) "HTTP/1.1"
  ["GATEWAY_INTERFACE"]=>
  string(7) "CGI/1.1"
  ["REDIRECT_STATUS"]=>
  string(3) "200"
  ["PATH_INFO"]=>
  string(15) "/myverytest.php"
  ["SCRIPT_FILENAME"]=>
  string(37) "/var/.../.../www/myverytest.php"
  ["PATH_TRANSLATED"]=>
  string(37) "/var/.../.../www/myverytest.php"
  ["PHP_SELF"]=>
  string(30) "/myverytest.php/myverytest.php"
}

I also tried changing the fastcgi_param directives with the following:

    fastcgi_param PATH_INFO $fastcgi_path_info;
    fastcgi_param SCRIPT_FILENAME $document_root$$fastcgi_path_info;       
    fastcgi_param PATH_TRANSLATED $document_root$$fastcgi_path_info;

or:

    fastcgi_param PATH_INFO $fastcgi_path_info;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;       
    fastcgi_param PATH_TRANSLATED $document_root$$fastcgi_path_info;

but I always see (in Firefox): "The page isn't redirecting properly"

Can you please check the above configuration?

@voku commented on October 22nd 2014

@noa-appletech I think you missed "fastcgi_split_path_info" -> http://wiki.nginx.org/PHPFcgiExample

PS: you can also take a look at my backup-config ;) -> https://github.com/voku/CONFIG--nginx---php-fpm---mysql/tree/master/etc/nginx

@noa-appletech commented on October 22nd 2014

Finally it worked fine after using the following fastcgi_param directives:

fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param SCRIPT_FILENAME $request_filename;

There is no fastcgi_split_path_info directive used in our case.

Thanks anyway, Nick

@mnapoli commented on October 22nd 2014

Thanks for the report everybody. A fix has been pushed to master, it will be released soon in 2.8.2.

This issue was closed on October 22nd 2014
Powered by GitHub Issue Mirror