Redirect error while Upgrading to 2.8.1 #6491

jochen42 · 2014-10-21T10:59:41Z

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.

The text was updated successfully, but these errors were encountered:

jochen42 · 2014-10-21T12:02:03Z

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

mnapoli · 2014-10-21T21:45:35Z

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 · 2014-10-21T21:48:59Z

hi mnapoli.

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

thx, jochen

mnapoli · 2014-10-21T22:04:16Z

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 · 2014-10-21T22:07:11Z

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 · 2014-10-21T22:11:00Z

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

mnapoli · 2014-10-21T22:31:32Z

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 · 2014-10-21T22:33:53Z

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 · 2014-10-21T22:34:57Z

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

voku · 2014-10-21T23:14:49Z

when I revert this commit 2aae308 || 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 · 2014-10-21T23:18:43Z

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 · 2014-10-21T23:19:21Z

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

jochen42 · 2014-10-21T23:36:51Z

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 · 2014-10-21T23:42:48Z

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 · 2014-10-21T23:48:14Z

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

jochen42 · 2014-10-21T23:51:04Z

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 · 2014-10-21T23:51:15Z

now everything works fine.

mnapoli · 2014-10-22T01:27:03Z

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;

… an incorrect PATH_INFO

mnapoli · 2014-10-22T01:59:54Z

@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: ad2c051

noa-appletech · 2014-10-22T13:11:52Z

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 · 2014-10-22T13:17:31Z

@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 · 2014-10-22T13:40:51Z

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 · 2014-10-22T21:30:15Z

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

mnapoli self-assigned this Oct 21, 2014

mnapoli added the Bug For errors / faults / flaws / inconsistencies etc. label Oct 21, 2014

mnapoli added a commit that referenced this issue Oct 22, 2014

#6491 Fixes a redirection loop when Nginx is misconfigured and passes…

ad2c051

… an incorrect PATH_INFO

mnapoli closed this as completed Oct 22, 2014

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Redirect error while Upgrading to 2.8.1 #6491

Redirect error while Upgrading to 2.8.1 #6491

jochen42 commented Oct 21, 2014

jochen42 commented Oct 21, 2014

mnapoli commented Oct 21, 2014

jochen42 commented Oct 21, 2014

mnapoli commented Oct 21, 2014

jochen42 commented Oct 21, 2014

jochen42 commented Oct 21, 2014

mnapoli commented Oct 21, 2014

jochen42 commented Oct 21, 2014

mnapoli commented Oct 21, 2014

voku commented Oct 21, 2014

mnapoli commented Oct 21, 2014

jochen42 commented Oct 21, 2014

jochen42 commented Oct 21, 2014

jochen42 commented Oct 21, 2014

voku commented Oct 21, 2014

jochen42 commented Oct 21, 2014

jochen42 commented Oct 21, 2014

mnapoli commented Oct 22, 2014

mnapoli commented Oct 22, 2014

noa-appletech commented Oct 22, 2014

voku commented Oct 22, 2014

noa-appletech commented Oct 22, 2014

mnapoli commented Oct 22, 2014

Redirect error while Upgrading to 2.8.1 #6491

Redirect error while Upgrading to 2.8.1 #6491

Comments

jochen42 commented Oct 21, 2014

jochen42 commented Oct 21, 2014

mnapoli commented Oct 21, 2014

jochen42 commented Oct 21, 2014

mnapoli commented Oct 21, 2014

jochen42 commented Oct 21, 2014

jochen42 commented Oct 21, 2014

mnapoli commented Oct 21, 2014

jochen42 commented Oct 21, 2014

mnapoli commented Oct 21, 2014

voku commented Oct 21, 2014

mnapoli commented Oct 21, 2014

jochen42 commented Oct 21, 2014

jochen42 commented Oct 21, 2014

jochen42 commented Oct 21, 2014

voku commented Oct 21, 2014

jochen42 commented Oct 21, 2014

jochen42 commented Oct 21, 2014

mnapoli commented Oct 22, 2014

mnapoli commented Oct 22, 2014

noa-appletech commented Oct 22, 2014

voku commented Oct 22, 2014

noa-appletech commented Oct 22, 2014

mnapoli commented Oct 22, 2014