NGINX: New install, admin redirect loop. Otherwise OK.

[kelvyn]

The server:
Ubuntu 11.10
Nginx 1.0.10
php-fpm 5.3.8

Brand new clean fresh install of Zen Cart 1.3.9h.
Installed perfectly - the only complaint was

PHP open_basedir restrictions = /var/www/clients/clientx/webx/web:/var/www/clients/clientx/webx/tmp:/var/www/xxx.co.uk/web:/srv/www/xxx.co.uk/web:/usr/share/php5:/tmp:/usr/share/phpmyadmin:/etc/phpmyadmin:/var/lib/phpmyadmin

but it said that didn't matter too much. And now the front end runs like a dream - REALLY fast even on a tiny underpowered VPS.

I can add things to my cart, I can go to secure checkout, the SSL works....

GREAT! Except when I try and access the admin login page...

This web page has a redirect loop
The web page at https://31.172.xxx.xxx/my-store/myadmin/login.php has resulted in too many redirects. Clearing your cookies for this site or allowing third-party cookies may fix the problem. If not, it is possibly a server configuration issue and not a problem with your computer.
Error 310 (net::ERR_TOO_MANY_REDIRECTS): There were too many redirects.

Here's what the browser diagnosis is showing me as it keeps redirecting:

https://31.172.xxx.xxx/my-store/myadmin/login.php?zenAdminID=csg401388f95i1nfuvfqn3imt4
https://31.172.xxx.xxx/my-store/myadmin/login.php?zenAdminID=0vtc775qcc8a8ekga7k1sp8sg5
https://31.172.xxx.xxx/my-store/myadmin/login.php?zenAdminID=87tmi164gqk4ji88vaicj0a5u1
https://31.172.xxx.xxx/my-store/myadmin/login.php?zenAdminID=j9oqih37fi35c1jj71hprrkue6

And here's some sample headers and responses from one of those redirects....

Request Headers

Request URL:https://31.172.xxx.xxx/my-store/myadmin/login.php?zenAdminID=t8b6f5i68r6rs3v8aiskgfa4l3
Request Method:GET
Status Code:302 Moved Temporarily
Request Headersview source
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8,en-GB;q=0.6
Cache-Control:max-age=0
Connection:keep-alive
Cookie:__utma=118755147.1755733436.1322859425.1322859425.1322864297.2; __utmb=118755147.16.10.1322864297; __utmc=118755147; __utmz=118755147.1322859425.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
Host:31.172.xxx.xxx

User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.59 Safari/535.7
Query String Parameters 
zenAdminID:t8b6f5i68r6rs3v8aiskgfa4l3

Response Headers
Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0

Connection:keep-alive
Content-Type:text/html; charset=iso-8859-1
Date:Fri, 02 Dec 2011 23:23:09 GMT
Expires:Thu, 19 Nov 1981 08:52:00 GMT
Location:https://31.172.xxx.xxx/my-store/myadmin/login.php?zenAdminID=jf9knnkrfoq9mdjptrh4lvgdr3
Pragma:no-cache
Server:nginx/1.0.10
Set-Cookie:zenAdminID=jf9knnkrfoq9mdjptrh4lvgdr3; path=/my-store/myadmin; domain=.31.172.xxx.xxx; HttpOnly
Transfer-Encoding:chunked
X-Powered-By:PHP/5.3.8-1~dotdeb.2

I've tried changing the sessions and cache from DB to file. I've looked in the cache dir for debug files - nothing. I've tried both http and https.
I've rebooted the VPS, my PC and the router to pick up another IP address.

I've cleared the browser cache and cookies, I've tried another browser, I've read the FAQs and the wiki. I've looked in the server error log (nothing). I've checked the file permissions. I've checked the php memory config.

And this all started when I tried to move a store from an apache to an nginx server. (Yes, I know there's a few rewrite changes for that other store, but with a brand new install with no add-ons, this shouldn't matter).

I know the server config is up to running stuff OK because I run a busy phpBB3 site on the same nginx-only config, as well as a Wordpress site fully loaded with lots of plugins.

There's something about that login file which is causing it to keep sending a new zenAdminID but I've been at this 9 hours now poring through the files, especially login.php and application_top and I'm just out of ideas now. Midnight now, so I'll call it a day, but any suggestions will be gratefully received and I promise to write a "Zen Cart on Nginx" Wiki if we find the solution!

[DrByte]

Sometimes numbered IP addresses will cause session problems. Using a proper FQDN fixes it.
So, set your HTTP_SERVER and HTTPS_SERVER settings to a proper named domain, and NOT an IP address, and I won't be surprised if things start working better.

[kelvyn]

Sometimes numbered IP addresses will cause session problems. Using a proper FQDN fixes it.
So, set your HTTP_SERVER and HTTPS_SERVER settings to a proper named domain, and NOT an IP address, and I won't be surprised if things start working better.

Ah, that was the one thing I forgot to mention - I started out with a named server, but as a last resort, tried IP address before posting here. It's back to its proper name.

Been at it again for a couple of hours this morning - something else I've done is to manually go into the db in phpmyadmin and change all the cookie settings - lots of permutation to be tried! Eventually ending up with all of the cookie settings set to false. And still I'm not in.

What exactly happens with the login page - I'm thinking of posting the problem on the nginx site. Does the login page use some server variable or feature which is exclusive to apache?

The reason I wonder this is because I'm able to completely go through the whole "add to cart, create account, ssl login, checkout, logout, log back in" as a customer. But if I try and get into admin, it's no good.

What about if I kept admin behind http basic auth - could I somehow reduce the checking done on that login.php page in order to just get into the admin side?

I've done yet another fresh install - here's what the access log says - and oddly, there's nothing in either the web server or php error log... you can see how quickly it just keeps hitting the server over and over - and watching from this end, I can see a new Zen Admin ID getting issued, several times a second. Strange, eh?

91.125.242.xxx - - [03/Dec/2011:10:29:54 +0000] "-" 400 0 "-" "-"
91.125.242.xxx - - [03/Dec/2011:10:29:54 +0000] "GET /zen/adminz/login.php HTTP/1.1" 302 5 "-" "Mozilla/5.0 "
91.125.242.xxx - - [03/Dec/2011:10:29:55 +0000] "-" 400 0 "-" "-"
91.125.242.xxx - - [03/Dec/2011:10:29:55 +0000] "GET /zen/adminz/login.php HTTP/1.1" 302 5 "-" "Mozilla/5.0 "
91.125.242.xxx - - [03/Dec/2011:10:29:55 +0000] "-" 400 0 "-" "-"
91.125.242.xxx - - [03/Dec/2011:10:29:55 +0000] "GET /zen/adminz/login.php HTTP/1.1" 302 5 "-" "Mozilla/5.0 "
91.125.242.xxx - - [03/Dec/2011:10:29:55 +0000] "-" 400 0 "-" "-"
91.125.242.xxx - - [03/Dec/2011:10:29:55 +0000] "GET /zen/adminz/login.php HTTP/1.1" 302 5 "-" "Mozilla/5.0 "
91.125.242.xxx - - [03/Dec/2011:10:29:55 +0000] "-" 400 0 "-" "-"
91.125.242.xxx - - [03/Dec/2011:10:29:55 +0000] "GET /zen/adminz/login.php HTTP/1.1" 302 5 "-" "Mozilla/5.0 "

[kelvyn]

Turning debugging on, I can see the following (but only in Opera, strangely...)

actionPoint=>0 include('/var/www/clients/client0/web1/web/zen/includes/classes/class.base.php');
actionPoint=>0 include('/var/www/clients/client0/web1/web/zen/includes/classes/class.notifier.php');
actionPoint=>0 $zco_notifier = new notifier();
actionPoint=>0 include('/var/www/clients/client0/web1/web/zen/includes/classes/sniffer.php');
actionPoint=>0 include('includes/classes/logger.php');
actionPoint=>0 include('/var/www/clients/client0/web1/web/zen/includes/classes/shopping_cart.php');
actionPoint=>0 include('/var/www/clients/client0/web1/web/zen/includes/classes/products.php');
actionPoint=>0 include('includes/classes/table_block.php');
actionPoint=>0 include('includes/classes/box.php');
actionPoint=>0 include('includes/classes/message_stack.php');
actionPoint=>0 include('includes/classes/split_page_results.php');
actionPoint=>0 include('includes/classes/object_info.php');
actionPoint=>0 include('/var/www/clients/client0/web1/web/zen/includes/classes/class.phpmailer.php');
actionPoint=>0 include('/var/www/clients/client0/web1/web/zen/includes/classes/class.smtp.php');
actionPoint=>0 include('includes/classes/upload.php');
actionPoint=>10 require('includes/init_includes/init_file_db_names.php');
actionPoint=>10 require('includes/init_includes/init_database.php');
actionPoint=>10 require('/var/www/clients/client0/web1/web/zen/includes/version.php');
actionPoint=>20 require('includes/init_includes/init_db_config_read.php');
actionPoint=>30 require('includes/init_includes/init_gzip.php');
actionPoint=>30 $sniffer = new sniffer();
actionPoint=>40 require('includes/init_includes/init_general_funcs.php');
actionPoint=>40 require('includes/init_includes/init_tlds.php');
actionPoint=>60 require('includes/init_includes/init_sessions.php');
actionPoint=>70 require('includes/init_includes/init_languages.php');
actionPoint=>80 require('includes/init_includes/init_templates.php');
actionPoint=>90 $zc_products = new products();
actionPoint=>90 require('includes/functions/localization.php');
actionPoint=>100 $messageStack = new messageStack();
actionPoint=>120 require('includes/init_includes/init_special_funcs.php');
actionPoint=>130 require('includes/init_includes/init_category_path.php');
actionPoint=>140 require('includes/init_includes/init_errors.php');

[DrByte]

There are a few things involved at this stage: sessions and server values.

If a session isn't properly started then it will not allow login. However, in that case it usually doesn't "loop" the way you've described.

And there are server values that the code depends on. PHP needs to get information from the webserver engine, and traditionally relies on the webserver being configured, as it traditionally is, to pass back appropriate commonly understood values to the $_SERVER superglobal array.
Try checking the values for $_SERVER['SCRIPT_FILENAME'] and $_SERVER['PHP_SELF'], perhaps at breakpoint 110.

[kelvyn]

And there are server values that the code depends on. PHP needs to get information from the webserver engine, and traditionally relies on the webserver being configured, as it traditionally is, to pass back appropriate commonly understood values to the $_SERVER superglobal array.
Try checking the values for $_SERVER['SCRIPT_FILENAME'] and $_SERVER['PHP_SELF'], perhaps at breakpoint 110.

Thanks for your quick reply, Dr - at the weekend too!

Apologies for being daft, but I don't actually know what you mean about "breakpoint 110"?

I know if I duplicated the site to an IDE like Netbeans, I can set a breakpoint, but I still don't know which 110 is! Did you mean Actionpoint? But I still don't see number 110.

What I CAN give you is the server variables which phpinfo gives me - does this look right?

PHP Variables

Variable	Value
_SERVER["USER"]	web1
_SERVER["HOME"]	/var/www/clients/clientx/webx
_SERVER["FCGI_ROLE"]	RESPONDER
_SERVER["QUERY_STRING"]	testquery=hello
_SERVER["REQUEST_METHOD"]	GET
_SERVER["CONTENT_TYPE"]	no value
_SERVER["CONTENT_LENGTH"]	no value
_SERVER["SCRIPT_FILENAME"]	/var/www/xxxx.co.uk/web/phpinf0.php
_SERVER["SCRIPT_NAME"]	/phpinf0.php
_SERVER["REQUEST_URI"]	/phpinf0.php
_SERVER["DOCUMENT_URI"]	/phpinf0.php
_SERVER["DOCUMENT_ROOT"]	/var/www/xxxx.co.uk/web
_SERVER["SERVER_PROTOCOL"]	HTTP/1.1
_SERVER["GATEWAY_INTERFACE"]	CGI/1.1
_SERVER["SERVER_SOFTWARE"]	nginx/1.0.10
_SERVER["REMOTE_ADDR"]	91.125.242.xx
_SERVER["REMOTE_PORT"]	49161
_SERVER["SERVER_ADDR"]	31.172.xxx.xxx
_SERVER["SERVER_PORT"]	80
_SERVER["SERVER_NAME"]	xxxx.co.uk
_SERVER["REDIRECT_STATUS"]	200
_SERVER["PATH_INFO"]	/phpinf0.php
_SERVER["HTTP_HOST"]	www.xxxx.co.uk
_SERVER["HTTP_CONNECTION"]	keep-alive
_SERVER["HTTP_USER_AGENT"]	Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.59 Safari/535.7
_SERVER["HTTP_ACCEPT"]	text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
_SERVER["HTTP_ACCEPT_ENCODING"]	gzip,deflate,sdch
_SERVER["HTTP_ACCEPT_LANGUAGE"]	en-US,en;q=0.8,en-GB;q=0.6
_SERVER["HTTP_ACCEPT_CHARSET"]	ISO-8859-1,utf-8;q=0.7,*;q=0.3
_SERVER["PHP_SELF"]	/phpinf0.php/phpinf0.php
_SERVER["REQUEST_TIME"]	1322946180

[DrByte]

_SERVER["PHP_SELF"] /phpinf0.php/phpinf0.php

There's likely your problem: the needlessly repeated filename in PHP_SELF.

I seem to recall that Windoze had a bug they had to fix in IIS a couple years back which was doing the same thing.
Maybe Nginx hasn't caught up yet.


And, yes, I did mean ActionPoint 110 ... sorry for the confusion. It's moot now anyway.

[kelvyn]

There's likely your problem: the needlessly repeated filename in PHP_SELF.

You beauty! That was it!

OK, with a few hours and a lot of googling, here's what I got:

I started here:
http://forum.nginx.org/read.php?11,2...439#msg-212439

which says (my emphasis)

decided to post my fastcgi_php.conf configuration file that helps me to resolve server environment compatibility issues with older PHP scripts that rely on PATH_INFO, PATH_TRANSLATED, SERVER_URL, SERVER_URI and PHP_SELF variables to be set correctly. Unfortunately, SCRIPT_NAME is not available, as if both SCRIPT_NAME and PHP_SELF are set in the FastCGI environment, PHP_SELF will eventually contain a concatenated string (a bug in PHP (F)CGI mode? - https://bugs.php.net/bug.php?id=55208)

Now, when I follow that bug tracker, it appears to be neither fixed nor closed, so the bug must still remain.

My server and config setup seems a little different to his, but eventually I worked out by trial and error that by commenting out
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
in /etc/nginx/fastcgi_params that made Zen cart login work! Hurrah!
Except, I found it then broke things like phpadmin - I get a 404 not found as soon as I enter username and password. I don't know why, it just does.



It seems to me that php server configs are set in both the params file - in my case /etc/nginx/fastcgi_params but can also be set "per location". So you remove fastcgi_param SCRIPT_NAME $fastcgi_script_name; from /etc/nginx/fastcgi_params to make Zen Cart work, and ADD it back into (in my case) /etc/nginx/sites-enabled/000-apps.vhost to make phpmyadmin work (phew!). Here's part of my 000-apps.vhost file now...

location /phpmyadmin {
          root /usr/share/;
          index index.php index.html index.htm;
          location ~ ^/phpmyadmin/(.+\.php)$ {
                  try_files $uri =404;
                  root /usr/share/;
                  include /etc/nginx/fastcgi_params; # THIS gets picked up first and needs the line fastcgi_param SCRIPT_NAME $fastcgi_script_name; removing
                  fastcgi_param SCRIPT_NAME $fastcgi_script_name; # THIS is what needs adding
# .... rest of file etc 

Then just issue
service nginx restart

and you're away and laughing!

I seem to recall that Windoze had a bug they had to fix in IIS a couple years back which was doing the same thing.
Maybe Nginx hasn't caught up yet.

It seems, in this case, to be more an issue with php-fpm than nginx. Why the bug hasn't been fixed I don't know, but I'll get onto them and add more info.

Meantime, big thanks for your help! I'll write all this up so it makes more sense in the next day or two, including the equivalent of the protection that .htaccess gives to certain location within Zen.