Forum: NGINX fastcgi problem

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Paul van der Linden (Guest)
on 2009-02-21 11:31
(Received via mailing list)
I was trying to install moin on fastcgi with nginx.
The problem is I only see the front page of the moin wiki, and any other
url don't seem to make its way through nginx to the fastcgi process. It
just displays the default page. Am I doing something wrong with my nginx
configuration?
My location configuration for moin :


        location / {
           fastcgi_pass   localhost:8888;
           fastcgi_index  moin.fcg;

           fastcgi_param  SCRIPT_FILENAME
/var/www/nginx-moin/$fastcgi_script_name;
           fastcgi_param  QUERY_STRING     $query_string;
           fastcgi_param  REQUEST_METHOD   $request_method;
           fastcgi_param  CONTENT_TYPE     $content_type;
           fastcgi_param  CONTENT_LENGTH   $content_length;
           fastcgi_param  DOCUMENT_URI       $document_uri;
           fastcgi_param  DOCUMENT_ROOT      /;

        }
Igor S. (Guest)
on 2009-02-21 12:24
(Received via mailing list)
On Sat, Feb 21, 2009 at 10:17:22AM +0100, Paul van der Linden wrote:

>            fastcgi_index  moin.fcg;
>         }
Googling I see that Moin wiki uses PATH_INFO to show a page.
Therefore, if you use "/" as wiki root, try the following:

        location / {
            fastcgi_pass   localhost:8888;

            fastcgi_param  PATH_INFO        $uri;
            fastcgi_param  QUERY_STRING     $query_string;
            fastcgi_param  REQUEST_METHOD   $request_method;
            fastcgi_param  CONTENT_TYPE     $content_type;
            fastcgi_param  CONTENT_LENGTH   $content_length;
        }
Paul van der Linden (Guest)
on 2009-02-21 12:29
(Received via mailing list)
Yes that works, I googled too, but apparently not good enough, thanks.
Igor S. (Guest)
on 2009-02-21 12:38
(Received via mailing list)
On Sat, Feb 21, 2009 at 11:23:11AM +0100, Paul van der Linden wrote:

> Yes that works, I googled too, but apparently not good enough, thanks.

What are the issues ?

BTW, in 0.7.31 the fastcgi_split_path_info had been introduced:

location /wiki {

    fastcgi_split_path_info         ^(/wiki)(.*)$;

    fastcgi_param  SCRIPT_NAME      $fastcgi_script_name;
    fastcgi_param  PATH_INFO        $fastcgi_path_info;
Paul van der Linden (Guest)
on 2009-02-21 13:51
(Received via mailing list)
Looks like there is no problem anymore. I was just saying that I didn't
search
good enough on google.
Ed W. (Guest)
on 2009-02-23 12:48
(Received via mailing list)
Paul van der Linden wrote:
>>>         location / {
>>>            fastcgi_pass   localhost:8888;
>>>            fastcgi_index  moin.fcg;
>>>


Remember also that this will cause any .php (or whatever cgi) files
anywhere on the filesystem to be executed.  It seems to be a pretty
common error for nginx PHP setups to use something like the above AND
also allow arbitrary named file uploads.  If the user of the php
application can cause some file to be uploaded with a .php extension
then point to it's disk path then the file will be executed.

Ed W
Cliff W. (Guest)
on 2009-02-23 15:13
(Received via mailing list)
On Mon, 2009-02-23 at 10:38 +0000, Ed W wrote:
> Paul van der Linden wrote:
> >>>         location / {
> >>>            fastcgi_pass   localhost:8888;
> >>>            fastcgi_index  moin.fcg;
> >>>
>
>
> Remember also that this will cause any .php (or whatever cgi) files
> anywhere on the filesystem to be executed.

Untrue (in this case), since Moin isn't a PHP application and Nginx
doesn't execute CGI scripts.   The only potential attack vector would be
to somehow upload a Python script and convince Moin to import it (quite
a bit trickier).

>   It seems to be a pretty
> common error for nginx PHP setups to use something like the above AND
> also allow arbitrary named file uploads.  If the user of the php
> application can cause some file to be uploaded with a .php extension
> then point to it's disk path then the file will be executed.

In the case of PHP, your above statements are true.   OTOH, the
situation becomes similar to that of Apache, so I'd think that this
isn't an Nginx-specific issue, but rather application-specific.

Regards,
Cliff
This topic is locked and can not be replied to.