load different robots in the same one “server” block
location ~ /robots.txt
{
if ($host = ‘first.domain’) {
rewrite ^/robots.txt /path/to/another/robots.txt last;
}
}
zhys9
------------------ Original ------------------
From: "nginx-request"[email protected];
Date: Sat, May 22, 2010 01:33 AM
To: "nginx"[email protected];
Subject: nginx Digest, Vol 7, Issue 47
Send nginx mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
nginx Info Page
or, via email, send a message with subject or body ‘help’ to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than “Re: Contents of nginx digest…”
Today’s Topics:
- Re: loading a different robots.txt file for a different sub
domain? (Ray) - Re: loading a different robots.txt file for a different sub
domain? (Ray) - Re: loading a different robots.txt file for a different sub
domain? (Ilan B.) - Re: loading a different robots.txt file for a different sub
domain? (Igor S.) - nginx 0day exploit for nginx + fastcgi PHP (Avleen Vig)
- Re: nginx 0day exploit for nginx + fastcgi PHP (Avleen Vig)
- Re: nginx 0day exploit for nginx + fastcgi PHP (Michael S.)
- Re: nginx 0day exploit for nginx + fastcgi PHP (Michael S.)
- Re: nginx 0day exploit for nginx + fastcgi PHP (Igor S.)
Message: 1
Date: Fri, 21 May 2010 21:53:45 +0800
From: Ray [email protected]
To: [email protected]
Cc: [email protected]
Subject: Re: loading a different robots.txt file for a different sub
domain?
Message-ID:
[email protected]
Content-Type: text/plain; charset=UTF-8
Yes.
server {
listen 80 default;
server_name www;
location /robots.txt {
alias /path/to/the/file1;
}
}
server {
listen 80;
server_name server2;
location /robots.txt {
alias /path/to/the/file2;
}
}
Ray.
On Fri, May 21, 2010 at 9:43 PM, Ilan B. [email protected]
wrote:
nginx mailing list
[email protected]
nginx Info Page
Message: 2
Date: Fri, 21 May 2010 21:53:45 +0800
From: Ray [email protected]
To: [email protected]
Cc: [email protected]
Subject: Re: loading a different robots.txt file for a different sub
domain?
Message-ID:
[email protected]
Content-Type: text/plain; charset=UTF-8
Yes.
server {
listen 80 default;
server_name www;
location /robots.txt {
alias /path/to/the/file1;
}
}
server {
listen 80;
server_name server2;
location /robots.txt {
alias /path/to/the/file2;
}
}
Ray.
On Fri, May 21, 2010 at 9:43 PM, Ilan B. [email protected]
wrote:
nginx mailing list
[email protected]
nginx Info Page
Message: 3
Date: Fri, 21 May 2010 10:03:10 -0400
From: Ilan B. [email protected]
To: [email protected]
Subject: Re: loading a different robots.txt file for a different sub
domain?
Message-ID:
[email protected]
Content-Type: text/plain; charset=“iso-8859-1”
Worked like a charm, thanks!
On Fri, May 21, 2010 at 9:53 AM, Ray [email protected] wrote:
Ray.
file when requested for one group vs. the other?
nginx mailing list
[email protected]
nginx Info Page
-------------- next part --------------
An HTML attachment was scrubbed…
URL:
http://nginx.org/pipermail/nginx/attachments/20100521/dc7ff991/attachment-0001.html
Message: 4
Date: Fri, 21 May 2010 18:24:01 +0400
From: Igor S. [email protected]
To: [email protected]
Subject: Re: loading a different robots.txt file for a different sub
domain?
Message-ID: [email protected]
Content-Type: text/plain; charset=koi8-r
On Fri, May 21, 2010 at 10:03:10AM -0400, Ilan B. wrote:
Worked like a charm, thanks!
You may also use:
location = /robots.txt {
}
(html, images, swf, etc.) but use different PHP backends.
nginx mailing list
[email protected]
nginx Info Page
nginx mailing list
[email protected]
nginx Info Page
–
Igor S.
http://sysoev.ru/en/
Message: 5
Date: Fri, 21 May 2010 10:07:00 -0700
From: Avleen Vig [email protected]
To: [email protected]
Subject: nginx 0day exploit for nginx + fastcgi PHP
Message-ID:
[email protected]
Content-Type: text/plain; charset=ISO-8859-1
This is currently doing the rounds, so I thought it pertinent to post
it here too.
http://www.webhostingtalk.com/showthread.php?p=6807475#post6807475
I don’t know what nginx should do to fix this, but there are two
workarounds given.
If you allow file uploads (especially things like images) and use PHP
FastCGI in the back end, you should take a loot at this now.
The exploit allows for any arbitrary file which is uploaded, to be
executed as PHP.
Message: 6
Date: Fri, 21 May 2010 10:27:14 -0700
From: Avleen Vig [email protected]
To: [email protected]
Subject: Re: nginx 0day exploit for nginx + fastcgi PHP
Message-ID:
[email protected]
Content-Type: text/plain; charset=ISO-8859-1
On Fri, May 21, 2010 at 10:07 AM, Avleen Vig [email protected] wrote:
executed as PHP.
I should add that this isn’t a bug in the traditional broken-code sense.
More that this is a gaping configuration hole which is now widely
published, and could lead to many people being exploited.
Message: 7
Date: Fri, 21 May 2010 10:28:16 -0700
From: Michael S. [email protected]
To: [email protected]
Cc: [email protected]
Subject: Re: nginx 0day exploit for nginx + fastcgi PHP
Message-ID:
[email protected]
Content-Type: text/plain; charset=UTF-8
Question is, what functionality is lost by changing
cgi.fix_pathinfo = 0
Looks like the other workaround is something like this:
if ( $fastcgi_script_name ~ ..*/.*php ) {
return 403;
}
Which i basically saying what exactly? If there is a period and slash
somewhere prior to the last “filename” to return a 403?
Ideally while this is being thought out it would be cool to fix the
common “no input file specified” issue that a lot of people have -
have it return a 404 instead. Not sure if it’s a simple php.ini change
(perhaps the path info?) or change fastcgi_param REDIRECT_STATUS 200?
On Fri, May 21, 2010 at 10:07 AM, Avleen Vig [email protected] wrote:
executed as PHP.
nginx mailing list
[email protected]
nginx Info Page
Message: 8
Date: Fri, 21 May 2010 10:28:16 -0700
From: Michael S. [email protected]
To: [email protected]
Cc: [email protected]
Subject: Re: nginx 0day exploit for nginx + fastcgi PHP
Message-ID:
[email protected]
Content-Type: text/plain; charset=UTF-8
Question is, what functionality is lost by changing
cgi.fix_pathinfo = 0
Looks like the other workaround is something like this:
if ( $fastcgi_script_name ~ ..*/.*php ) {
return 403;
}
Which i basically saying what exactly? If there is a period and slash
somewhere prior to the last “filename” to return a 403?
Ideally while this is being thought out it would be cool to fix the
common “no input file specified” issue that a lot of people have -
have it return a 404 instead. Not sure if it’s a simple php.ini change
(perhaps the path info?) or change fastcgi_param REDIRECT_STATUS 200?
On Fri, May 21, 2010 at 10:07 AM, Avleen Vig [email protected] wrote:
executed as PHP.
nginx mailing list
[email protected]
nginx Info Page
Message: 9
Date: Fri, 21 May 2010 21:33:02 +0400
From: Igor S. [email protected]
To: [email protected]
Subject: Re: nginx 0day exploit for nginx + fastcgi PHP
Message-ID: [email protected]
Content-Type: text/plain; charset=koi8-r
On Fri, May 21, 2010 at 10:07:00AM -0700, Avleen Vig wrote:
executed as PHP.
I do not see why this is treated as nginx bug ?
Why is anyone able at all to upload images to /scripts directory ?
Why does PHP have cgi.fix_pathinfo option ?
BTW, I’m just curious how does lighttpd resolve this issue ?
Also instead of
if ( $fastcgi_script_name ~ ..*/.*php ) {
return 403;
}
it should be worked around as
location ~ ../..php$ {
return 403;
}
location ~ .php$ {
return 403;
}
–
Igor S.
http://sysoev.ru/en/
nginx mailing list
[email protected]
http://nginx.org/mailman/listinfo/nginx
End of nginx Digest, Vol 7, Issue 47