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

[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.