NGINX Problems

[Yag Po Khyi]

Hi,

as this is my first post here I would like to thank for all the good
work!

I am having problems to get things configured with nginx - the
notorious "no input file" error bugs me and if I change configurations
I get a blank screen and noting happens - seems like simplesamlphp is
somewhat Apache bound, what I would like to suggest would be great to
rethink - nginx is really a great peice of software!

Well, before touchig the code myself I would like to ask if anybody
has a working configuration with nginx for the actual simplesamlphp
release? Would be really appreciated!

Thank you for your attention!
Yag Po Khyi

[Olav Morken]

On Sun, Feb 06, 2011 at 16:02:10 -0800, Yag Po Khyi wrote:
> Hi,
>
> as this is my first post here I would like to thank for all the good
> work!
>
> I am having problems to get things configured with nginx - the
> notorious "no input file" error bugs me

Could you elaborate about what you mean with «"no input file" error»?
Does it come from simpleSAMLphp? What URL gives you that error? Do you
get a stack trace or anything like that?

> and if I change configurations

Change configurations in which way?

> I get a blank screen and noting happens

Have you checked your log files? I don't know where PHP logs error
when running under nginx, but presumably there is a log file somewhere?

> - seems like simplesamlphp is
> somewhat Apache bound, what I would like to suggest would be great to
> rethink - nginx is really a great peice of software!

It should not be Apache bound, but we are only testing on Apache, so
there may be bugs that means it will only work under Apache. Those bugs
should probably be fixed, but we must first determine what they are.

Regards,
Olav Morken
UNINETT / Feide

[comel]

We use SSP with nginx and you have to set "fastcgi_param PATH_INFO".
We have
slightly specific configuration, but the important parts look
something
like this:

-----------
if ($uri ~ "^/ssp/module.php(/casserver/cas|/openidProvider/user|/
knopso/OpenID/User|/saml2/sp/logout|/saml/sp/(metadata|saml1-acs|saml2-
acs|saml2-logout))([^\.]?.*)$") {
set $custom_script_filename $document_root/module.php;
set $custom_script_name /ssp/module.php;
set $custom_path_info $1.php$3;
}

include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $custom_script_filename;
fastcgi_param SCRIPT_NAME $custom_script_name;
fastcgi_param PATH_INFO $custom_path_info;
-----------

[Olav Morken]

On Wed, Feb 09, 2011 at 02:11:02 -0800, comel wrote:
> On 7 velj, 01:02, Yag Po Khyi <server...@gmail.com> wrote:
> > Hi,
> >
> > as this is my first post here I would like to thank for all the good
> > work!
> >
> > I am having problems to get things configured with nginx - the
> > notorious "no input file" error bugs me and if I change configurations
> > I get a blank screen and noting happens - seems like simplesamlphp is
> > somewhat Apache bound, what I would like to suggest would be great to
> > rethink - nginx is really a great peice of software!
> >
> > Well, before touchig the code myself I would like to ask if anybody
> > has a working configuration with nginx for the actual simplesamlphp
> > release? Would be really appreciated!
>
> We use SSP with nginx and you have to set "fastcgi_param PATH_INFO".

So nginx does not directly support PATH_INFO. That's a bit
disappointing, since PATH_INFO is part of the CGI specification. It
also explains the failures, since SSP relies heavily on this
functionality.

> We have
> slightly specific configuration, but the important parts look
> something
> like this:
>
> -----------
> if ($uri ~ "^/ssp/module.php(/casserver/cas|/openidProvider/user|/
> knopso/OpenID/User|/saml2/sp/logout|/saml/sp/(metadata|saml1-acs|saml2-
> acs|saml2-logout))([^\.]?.*)$") {
> set $custom_script_filename $document_root/module.php;
> set $custom_script_name /ssp/module.php;
> set $custom_path_info $1.php$3;
> }
>
> include fastcgi_params;
> fastcgi_param SCRIPT_FILENAME $custom_script_filename;
> fastcgi_param SCRIPT_NAME $custom_script_name;
> fastcgi_param PATH_INFO $custom_path_info;
> -----------

There is also an example of a configuration at:

http://wiki.nginx.org/HttpFcgiModule#fastcgi_split_path_info

That example appears to be a bit more generic, but I suspect that you
will also need to assign the SCRIPT_NAME option.

[Yag Po Khyi]

Hi, comel, is this a real-life-proven config? Does everything work
with it without errors? Thank you very much for sharing it - I will
try!

Olav, in fact relying on PATH_INFO is not good practice in PHP world,
as far as I know the story behind PATH_INFO has some dark areas - I do
not know the complete facts, however it comes down to the one
important thing that PATH_INFO is not reliable across servers and
platforms - especially in fastcgi environments - but with a SSO
solution that might get many hits you probably would like to use a
fastcgi deployment, expecially nginx is really a nice piece of
software when it comes to handling many connections, beeing a
loadbalancer etc. - of course you still want your central SSO software
to be reliable in any circumstances.

That is why I would like to propose NOT to use PATH_INFO - I made some
experiments yesterday, I still do not understand your code in all
details, however here is a very simple solution to get rid of
PATH_INFO in module.php:

please add in module.php right after

require_once('_include.php');

$config = SimpleSAML_Configuration::getInstance();
if ($config->getBoolean('php.pathinfo_from_requesturi', TRUE)) {
SimpleSAML_Logger::debug('!!! ATTENTION: USING REQUEST_URI TO
GENERATE PATH_INFO !!!');

// helper function to get pathinfo http://php.net/manual/en/function.strstr.php
function strstr_after($haystack, $needle, $case_insensitive = false)
{
$strpos = ($case_insensitive) ? 'stripos' : 'strpos';
$pos = $strpos($haystack, $needle);
if (is_int($pos)) {
return substr($haystack, $pos + strlen($needle));
}
// Most likely false or null
return $pos;
}

$url_path = parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH);
$pathinfo = strstr_after($url_path,'module.php');

SimpleSAML_Logger::debug('REQUEST_URI: '.$_SERVER['REQUEST_URI']);
SimpleSAML_Logger::debug('URL_PATH : '.$url_path);
SimpleSAML_Logger::debug('PATH_INFO : '.$_SERVER['PATH_INFO']);
SimpleSAML_Logger::debug('PATH_INFO_X: '.$pathinfo);

$_SERVER['PATH_INFO'] = $pathinfo;

}


then append to config.php these lines:

/*
* Use $_SERVER['REQUEST_URI'] to generate $_SERVER['PATH_INFO']
* This is helpful with a fastcgi deployment, where you might have
* problems getting $_SERVER['PATH_INFO'] in en expected way
*/
'php.pathinfo_from_requesturi' => TRUE,


This seems to work - but I am still not sure - however I post it here
as a starting point. It would be much better for fastcgi deployments
to use REQUEST_URI for path-building - currently getting SSP reliably
working with anything else than apache is a little bit complicated -
and the content of PATH_INFO is not reliable with Apache either! - it
would be great to have it support many different deployment scenarios
right out of the box - what can be achieved simply by avoiding
PATH_INFO.

There are some more files containing PATH_INFO - I still have to check
about these, but I think most functionality is not broken with the
code above. It would be really great if you could check this for side-
effects I might not know yet.

Also I found one special place that does not work with this: /core/
authenticate.php?as=admin&logout
This link is generated without module.php in the URI - I do not
understand why, I did not even find the right place where this logout
link is generated, however with the code above it should be /
module.php/core/authenticate.php?as=admin&logout to work - all the
other links are correctly generated with the /module.php in front. Don
´t know wha is wrong here... might be a little thing, but I can not
find it.

Hopefully changing the other bits of the code not to be dependant on
PATH_INFO can be very easily done based on the code above. Please,
Olav, consider this as a quick healing and making SSP available in a
reliable way on many different servers - would be a great help!

Thank you very much for you attention,
Yag Po Khyi

[Olav Morken]

On Thu, Feb 10, 2011 at 06:20:31 -0800, Yag Po Khyi wrote:
> Hi, comel, is this a real-life-proven config? Does everything work
> with it without errors? Thank you very much for sharing it - I will
> try!
>
> Olav, in fact relying on PATH_INFO is not good practice in PHP world,
> as far as I know the story behind PATH_INFO has some dark areas - I do
> not know the complete facts, however it comes down to the one
> important thing that PATH_INFO is not reliable across servers and
> platforms - especially in fastcgi environments - but with a SSO
> solution that might get many hits you probably would like to use a
> fastcgi deployment, expecially nginx is really a nice piece of
> software when it comes to handling many connections, beeing a
> loadbalancer etc. - of course you still want your central SSO software
> to be reliable in any circumstances.
>
> That is why I would like to propose NOT to use PATH_INFO

That is not an option at this point (and I don't think it was ever an
option when we decided to try to modularize SSP). We need the ability
to have one script (module.php) pass the request on to a different
script, and we cannot use query parameters to do it.

I'm not certain, but I think you need to set $_SERVER['SCRIPT_NAME']
in addition to PATH_INFO.

>
> }
>
>
> then append to config.php these lines:
>
> /*
> * Use $_SERVER['REQUEST_URI'] to generate $_SERVER['PATH_INFO']
> * This is helpful with a fastcgi deployment, where you might have
> * problems getting $_SERVER['PATH_INFO'] in en expected way
> */
> 'php.pathinfo_from_requesturi' => TRUE,
>
>
> This seems to work - but I am still not sure - however I post it here
> as a starting point. It would be much better for fastcgi deployments
> to use REQUEST_URI for path-building - currently getting SSP reliably
> working with anything else than apache is a little bit complicated -
> and the content of PATH_INFO is not reliable with Apache either!

In which case is PATH_INFO not reliable with Apache?

> - it
> would be great to have it support many different deployment scenarios
> right out of the box - what can be achieved simply by avoiding
> PATH_INFO.
>
> There are some more files containing PATH_INFO - I still have to check
> about these, but I think most functionality is not broken with the
> code above. It would be really great if you could check this for side-
> effects I might not know yet.

I think all other scripts using PATH_INFO are running under module.php,
so as long as the PATH_INFO is correct going into module.php, those
scripts will work.

> Also I found one special place that does not work with this: /core/
> authenticate.php?as=admin&logout
> This link is generated without module.php in the URI - I do not
> understand why, I did not even find the right place where this logout
> link is generated, however with the code above it should be /
> module.php/core/authenticate.php?as=admin&logout to work - all the
> other links are correctly generated with the /module.php in front. Don
> ´t know wha is wrong here... might be a little thing, but I can not
> find it.

This may be caused by the missing $_SERVER['SCRIPT_NAME'] (if it is
missing).

> Hopefully changing the other bits of the code not to be dependant on
> PATH_INFO can be very easily done based on the code above. Please,
> Olav, consider this as a quick healing and making SSP available in a
> reliable way on many different servers - would be a great help!

I think configuring nginx differently is a better approach. Since they
have added the 'fastcgi_split_path_info'-directive[1], presumably the
correct way to use PATH_INFO with nginx is to do it using that
directive.

In addition to the example present in the documentation for the
directive, I would guess that you also need to set the SCRIPT_NAME
option, using something like:

fastcgi_param SCRIPT_NAME $fastcgi_script_name;

[1] http://wiki.nginx.org/HttpFcgiModule#fastcgi_split_path_info

[comel]

On 10 velj, 15:20, Yag Po Khyi <server...@gmail.com> wrote:
> Hi,  comel, is this a real-life-proven config? Does everything work
> with it without errors?

Yes and yes! We use slightly custom configuration because of custom
URL rewriting. In standard configuration you only need something like
this (assuming SSP baseurlpath = 'ssp/'):

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

include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
-------------------------------------------

In most distributions you even don't have to specify SCRIPT_FILENAME/
SCRIPT_NAME because they included in fastcgi_params file.

[Yag Po Khyi]

Hi comel,

for some strange reasons I do not understand right now the
configuration does not work for me :(

I have also one more meta-problem, that is PATH_INFO set by NGINX if
it should be empty it actually is never empty but filled with random
garbage... well, I am leaving off the nginx road for simplesamlphp
right now, SAML is complicated enough for me, I do not need another
layer of complexitiy and errors atm - back to good old apache :)

However, would be great to have this working with fastcgi deployments
right out-of-the box :)

Olav: about PATH_INFO I can tell you that if you start doing fastcgi
deployments it will give you a constant source of trouble with
different pieces of software / servers / configurations. Also I think
it can almost anytime be completely replaced by REQUEST_URI.

PATH_INFO is an option in several places, apache core configuration
has AcceptPathInfo, php.ini has switches to manipulate PATH_INFO, and
there are several servers that give you unexpected results on what you
would like to see in PATH_INFO - so here are many layers of
confusion :) REQUEST_URI is AFAIK a clean and solid solution for
PATH_INFO problems of all kinds - and should be easily usable in every
case PATH_INFO is used.

Please do not ask me about why these PATH_INFO problems exist - I do
not understand why all this mess happened and who started it, I only
can assure you that these problems in fact do exist - some pseudo-
statistical evidence: search google for PATH_INFO+problems - currently
2.770.000 results - REQUEST_URI+problems - only 143.000 results :)

Thank you very much for your attention!
Yag Po Khyi

[psylovibe]

I completely agree. I just ran into this issue just now. It's sad that this does not come out of the box to work with other webservers.
It would be nice to list this in the prerequisites, and or offer a solution.

[Thijs Kinkhorst]

Hi,

On Fri, 28 Dec 2012 12:25:36 -0800 (PST), psylovibe
<theofan...@gmail.com> wrote:
> I completely agree. I just ran into this issue just now. It's sad that
> this does not come out of the box to work with other webservers.
> It would be nice to list this in the prerequisites, and or offer a
> solution.

Since you ran into the problem, you're probably in a good position to
describe what went wrong and how to solve it. I'm sure that the developers
would gladly merge your proposed documentation improvements.


--
Thijs Kinkhorst <th...@uvt.nl> – LIS Unix

Universiteit van Tilburg – Library and IT Services
Bezoekadres > Warandelaan 2 • Tel. 013 466 3035 • G 236

[psylovibe]

The solution is not so bad.

I had to setup a location in my nginx configuration.

    location ~ ^/module\.php {
        alias /simplesaml/www;
        include /usr/local/etc/nginx/fastcgi_params;
        fastcgi_param   SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass    127.0.0.1:9000;
        fastcgi_index   index.php;
        fastcgi_read_timeout 600;
        fastcgi_split_path_info (^\/module\.php)(/.+)$;
        fastcgi_param PATH_INFO  $fastcgi_path_info;
    }

I just never really use PATH_INFO in my apps maybe back in 2008.

Perhaps setting up a APPLICATION_PATH define would be a good solution

defined('APPLICATION_PATH')
    || define('APPLICATION_PATH', realpath(realpath(__DIR__));

[Harold Aling]

Well,

I thought I understood Nginx configuration ... I was wrong ;)

For a client, we need to set up a Drupal site that authenticates against a SAML provider. We run Nginx and unfortunately, there's no documentation on how to get it up and running.

The configuration posted by psylovibe also doesn't work: it only spews out the infamous "File not found." error, paired with this error.log entry:

2013/10/29 16:43:03 [error] 23933#0: *1 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 192.168.13.80, server: *****, request: "GET /simplesaml/ HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "*****"

I've tried all possible combinations with and without /www, $1, etc ... :(

location ~ ^/simplesaml/(.+\.php.*)$ {

  include fastcgi_params;

# alias /var/www/drupal/sites/all/libraries/simplesamlphp;

# alias /var/www/drupal/sites/all/libraries/simplesamlphp/$1;

# alias /var/www/drupal/sites/all/libraries/simplesamlphp/www;

  alias /var/www/drupal/sites/all/libraries/simplesamlphp/www/$1;

  fastcgi_split_path_info ^(.+\/module\.php)(/.+)$;

  fastcgi_pass unix:/var/run/php5-fpm.sock;

  fastcgi_index index.php;

  fastcgi_intercept_errors on;

  fastcgi_param PATH_INFO $fastcgi_path_info;

# fastcgi_param SCRIPT_FILENAME /var/www/drupal/sites/all/libraries/simplesamlphp$fastcgi_script_name;

# fastcgi_param SCRIPT_FILENAME /var/www/drupal/sites/all/libraries/simplesamlphp/www$fastcgi_script_name;

# fastcgi_param SCRIPT_FILENAME /var/www/drupal/sites/all/libraries/simplesamlphp$request_filename;

  fastcgi_param SCRIPT_FILENAME /var/www/drupal/sites/all/libraries/simplesamlphp/www$request_filename;

# fastcgi_param DOCUMENT_ROOT   /var/www/drupal/sites/all/libraries/simplesamlphp;

# fastcgi_param DOCUMENT_ROOT   /var/www/drupal/sites/all/libraries/simplesamlphp/www;

}

"/var/www/dvg/sites/all/libraries/simplesamlphp" is the folder where I've extracted simplesamlphp-1.11.0.tar.gz.

Help?!?

Harold

[comel]

simpleSAMLphp is not different as any other PHP application which uses PHP_INFO, take a look at http://wiki.nginx.org/PHPFcgiExample.

[Harold Aling]

Comel,

After hours spent on IRC, I've managed to get Nginx/SimpleSAMLphp up
and running!

server {
server_name *.drupal.harold.lan drupal.harold.lan;
root /var/www/drupal; ## <-- Your Drupal path reference.

include php_fpm;
include drupal;

location ^~ /simplesaml {
alias /var/www/drupal/sites/all/libraries/simplesamlphp/www; ##
<-- The absolute path to the simplesamlphp library.

location ~ ^(?<prefix>/simplesaml)(?<phpfile>.+?\.php)(?<pathinfo>/.*)?$ {
include fastcgi_params;
fastcgi_pass unix:/var/run/php5-fpm.sock;

fastcgi_param SCRIPT_FILENAME $document_root$phpfile;
fastcgi_param PATH_INFO $pathinfo if_not_empty;
}
}
}

I'll make sure this gets documented somewhere (official?), once I'm
absolutely sure this works 100%.

Cheers!


Harold

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "simpleSAMLphp" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/simplesamlphp/39m7XUEjsb4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> simplesamlph...@googlegroups.com.
> To post to this group, send email to simple...@googlegroups.com.
> Visit this group at http://groups.google.com/group/simplesamlphp.
> For more options, visit https://groups.google.com/groups/opt_out.

[comel]

You will also want to set SCRIPT_NAME to something like $prefix$phpfile.

[Peter Schober]

* Harold Aling <har...@sait.nl> [2013-10-31 09:31]:
> fastcgi_param SCRIPT_FILENAME $document_root$phpfile;

Maybe needed for Drupal but SimpleSAMLphp doesn't care about
SCRIPT_FILENAME (at least not until 1.10).
It does care about SCRIPT_NAME though, like Comel said.
-peter

[Harold Aling]

This configuration works, even without explicit SCRIPT_NAME. Dropping
the SCRIPT_FILENAME results in a "File not found" error, and an entry
in the error.log "Primary script unknown".

-H-

[comel]

Please verify output of SimpleSAML_Utilities::selfURLNoQuery() without SCRIPT_NAME set in nginx (by default this is probably SCRIPT_NAME $fastcgi_script_name).

[comel]

But PHP does care for SCRIPT_FILENAME, and it has to be set.

[Harold Aling]

Adding "var_dump(SimpleSAML_Utilities::selfURLNoQuery());" in
module.php, right after "require_once('_include.php');" dumps the
correct and absolute urls.

In my case: "http://test.harold.lan/simplesaml/module.php/core/frontpage_config.php"

[comel]

OK, I do not know your other fastcgi_param settings included from "fastcgi_params", but if you will write some howto, make sure that you include all fastcgi_param settings, and whether the php.ini cgi.fix_pathinfo is enabled or disabled. Including output of $_SERVER is also useful.