On 8/16/08, Igor S. [email protected] wrote:
Have you tried
location ~ /wordpress/admin.* {
location ^~ /wordpress/admin {?
yeah - it did not work. PHP (the nested fastcgi location inside of the
admin location) was not processing anymore.
On Sat, Aug 16, 2008 at 03:19:23AM -0700, mike wrote:
index index.php index.html; } location ~ \.php$ { fastcgi_pass 127.0.0.1:11000; } }apparently the regex i tried earlier for admin was wrong. i had the
right idea though.
Have you tried
-
location ~ /wordpress/admin.* {
-
location ^~ /wordpress/admin {
?
i would like to know what the behavior will be when you apply the
dirlist patch to know if i need to adjust my side or not. thanks
You will not need to adjust anything.
On 8/16/08, Igor S. [email protected] wrote:
As to patch, after looking the code, I have found that EACESS at this
point should be ignored. Here is my patch (the same as Maxim’s one)
with comment. Could you or someone test English part of patch ?
i figured out - i need to use “p0” with your patches and they patch
directly. okay. first question resolved 
root@local:/usr/src/build/nginx-0.7.10# patch -p0 <
…/nginx-patches/0.7.10-dirtest.txt
patching file src/http/modules/ngx_http_index_module.c
root@local:/usr/src/build/nginx-0.7.10# patch -p0 <
…/nginx-patches/0.7.10-staticpost.txt
patching file src/http/modules/ngx_http_static_module.c
root@local:/usr/src/build/nginx-0.7.10#
I’m testing the dirtest thing now:
2008/08/16 12:23:06 [debug] 8277#0: *34 open index
“/home/mike/web/192.168.1.3/index.5”
2008/08/16 12:23:06 [debug] 8277#0: *34 add cleanup: 00000000007FD948
2008/08/16 12:23:06 [debug] 8277#0: *34 open()
“/home/mike/web/192.168.1.3/index.5” failed (2: No such file or
directory)
2008/08/16 12:23:06 [debug] 8277#0: *34 http index check dir:
“/home/mike/web/192.168.1.3”
2008/08/16 12:23:06 [debug] 8277#0: *34 add cleanup: 00000000007FD978
2008/08/16 12:23:06 [debug] 8277#0: *34 open index
“/home/mike/web/192.168.1.3/index.html”
2008/08/16 12:23:06 [debug] 8277#0: *34 add cleanup: 00000000007FD9A8
So it looks like it still does your dir check like before, it just
doesn’t throw an error on access denied?
I have it set to
index index.5 index.html index.4 index.3;
and the actual file is index.html, so it has to fail the first one to
move on.
all the directories are also chmod 0711. it appears to work… it
looks like http index check dir does not cause the request to be
denied even if it doesn’t have permission… which i suppose is all i
care about. in theory that dir check i still don’t think needs to be
there until it has exhausted all the user-defined index files… but
as long as directory mode 0711 doesn’t break anything i’m happy for
now.
On Sat, Aug 16, 2008 at 12:05:17PM -0700, mike wrote:
admin location) was not processing anymore.
Yes, this is a bug. I’m looking how to resolve it.
On 8/16/08, Igor S. [email protected] wrote:
yeah - it did not work. PHP (the nested fastcgi location inside of the
admin location) was not processing anymore.Yes, this is a bug. I’m looking how to resolve it.
well the regex i’m using -is- working for now. but i would like to
have my configuration fully Igor approved
right now everything is working great - the dirtest patch, the nested
location block with the regex. i can’t really test the static post
behavior (unless it’s transparent in the background) or would it be a
POST to a file that is being referenced from error_page 404 =
/wordpress/index.php?q=$request_uri; ?
If so, I need to setup a test at home using an error_page 404 handler
that actually accepts the post data (if you want someone else to
check)
For your reference this is working 100% correctly right now it appears:
server {
listen 80;
server_name foo.com;
index index.php index.html;
root /home/mike/web/foo.com/;
include /etc/nginx/defaults.conf;
include /etc/nginx/expires.conf;
error_page 404 = /wordpress/index.php?q=$request_uri;
location ~ /wordpress/admin.* {
auth_basic "wordpress";
auth_basic_user_file
/home/mike/web/foo.com/.htpasswd;
location ~ .php$ {
fastcgi_pass 127.0.0.1:11000;
}
}
location ~ .php$ {
fastcgi_pass 127.0.0.1:11000;
}
}
using 0.7.10 + your latest dirtest patch + your static post patch.
debug is enabled too.
On Sat, Aug 16, 2008 at 12:39:13PM -0700, mike wrote:
On 8/16/08, Igor S. [email protected] wrote:
yeah - it did not work. PHP (the nested fastcgi location inside of the
admin location) was not processing anymore.Yes, this is a bug. I’m looking how to resolve it.
well the regex i’m using -is- working for now. but i would like to
have my configuration fully Igor approved
Yes, now you should use regex.
right now everything is working great - the dirtest patch, the nested
location block with the regex. i can’t really test the static post
behavior (unless it’s transparent in the background) or would it be a
POST to a file that is being referenced from error_page 404 =
/wordpress/index.php?q=$request_uri; ?If so, I need to setup a test at home using an error_page 404 handler
that actually accepts the post data (if you want someone else to
check)
error_page 404 = /wordpress/index.php?q=$request_uri;
handles both GETs and POSTs to non-existent files.
On 8/16/08, Igor S. [email protected] wrote:
Yes. For the reason described in patch’s comment:
/* * ngx_http_index_test_dir() is called after the first index * file testing has returned an error distinct from NGX_EACCES. * This means that directory searching is allowed. */
I’m not knowledgeable enough to know if that makes sense from a
syscall/coding perspective. But it sounds right. You don’t typically
put comments in the code from what I’ve seen; feel free to remove the
comment, I don’t need it for my sake
On Sat, Aug 16, 2008 at 12:28:12PM -0700, mike wrote:
…/nginx-patches/0.7.10-dirtest.txt
2008/08/16 12:23:06 [debug] 8277#0: *34 add cleanup: 00000000007FD948
So it looks like it still does your dir check like before, it just
doesn’t throw an error on access denied?
Yes. For the reason described in patch’s comment:
/*
* ngx_http_index_test_dir() is called after the first
index
* file testing has returned an error distinct from
NGX_EACCES.
* This means that directory searching is allowed.
*/
Could you check English of the comment ?
On Sat, Aug 16, 2008 at 11:29:54PM +0400, Igor S. wrote:
yeah - it did not work. PHP (the nested fastcgi location inside of the
admin location) was not processing anymore.Yes, this is a bug. I’m looking how to resolve it.
Looking at code, I’ve found that simple should work:
location /wordpress/admin {
If nginx has found maximum static match, it look inclusive static and
regex locations. The matched inclusive regex location stops searching.
It seems that inclusive locations should be documented: forgot how they
works :).
On Sat, Aug 16, 2008 at 12:57:26PM -0700, mike wrote:
I’m not knowledgeable enough to know if that makes sense from a
syscall/coding perspective. But it sounds right.
OK, then I will commit in this form.
You don’t typically
put comments in the code from what I’ve seen; feel free to remove the
comment, I don’t need it for my sake
I put comments where case is not obvious for me.
On Sun, Aug 17, 2008 at 12:07:22AM +0400, Igor S. wrote:
If nginx has found maximum static match, it look inclusive static and
regex locations. The matched inclusive regex location stops searching.
In other words, inclusive regex locations have higher priority.
On Sat, Aug 16, 2008 at 02:33:33PM -0700, mike wrote:
I will try that again when I get home but I brought this up again
because I realized it wasn’t fully protected after all. Does it matter
what order of location blocks are defined ?
It matters for regex only:
On Sat, Aug 16, 2008 at 2:46 PM, Igor S. [email protected] wrote:
It matters for regex only:
Yeah, this page is great but it is -really- confusing, I try to read
it over and over to fully understand it. Thank god there is this
mailing list and help!
I will try that again when I get home but I brought this up again
because I realized it wasn’t fully protected after all. Does it matter
what order of location blocks are defined ?
On Sat, Aug 16, 2008 at 03:00:34PM -0700, mike wrote:
works :).
this does not:location ~ \.php$ { fastcgi_pass 127.0.0.1:11000; }
The attached patch should fix two inclusive bugs.
If will not help, the current workaround is to use one level locations:
location ~ /wordpress/wp-admin {
auth
}
location ~ /wordpress/wp-admin/.*\.php$ {
auth
fastcgi
}
location ~ \.php$ {
fastcgi
}On Sat, Aug 16, 2008 at 1:07 PM, Igor S. [email protected] wrote:
Looking at code, I’ve found that simple should work:
location /wordpress/admin {If nginx has found maximum static match, it look inclusive static and
regex locations. The matched inclusive regex location stops searching.It seems that inclusive locations should be documented: forgot how they
works :).
this works:
location ~ /wordpress/wp-admin.* {
auth_basic “wordpress”;
auth_basic_user_file
/home/mike/web/foo.com/.htpasswd;
location ~ .php$ {
fastcgi_pass 127.0.0.1:11000;
}
}
this does not:
location /wordpress/admin/ {
auth_basic "wordpress";
auth_basic_user_file
/home/mike/web/foo.com/.htpasswd;
location ~ .php$ {
fastcgi_pass 127.0.0.1:11000;
}
}
and this is the only other location block in that server block…
location ~ \.php$ {
fastcgi_pass 127.0.0.1:11000;
}
On 8/16/08, Igor S. [email protected] wrote:
fastcgi}
location ~ .php$ {
fastcgi
}
I love how small code-wise these changes are for such functional
differences. nginx is a technical marvel - so much functionality with
such little code!
I will try out this patch, but I am curious - why isn’t my existing
method using the plain old /wordpress/wp-admin.* regex an acceptable
workaround (until this “bug” as you’ve said is fixed) - or is this
patch the “fix” for that behavior, if it works?
On 8/17/08, Igor S. [email protected] wrote:
}
location ~ .php$ {
location /wordpress/wp-admin {
authlocation ~ \.php$ { fastcgi }}
location ~ .php$ {
fastcgi
}
okay, so which out of these is the most efficient method? Maybe our
language barrier is confusing me but I am not sure which method you
are recommending or are saying is fixed/not fixed/the proper way…
i’m on a 0.7.10 build now with the following 3 patches:
root@local:/usr/src/build/nginx-0.7.10# patch -p0 <
…/nginx-patches/0.7.10-inclusive.txt
patching file src/http/ngx_http_core_module.c
root@local:/usr/src/build/nginx-0.7.10# patch -p0 <
…/nginx-patches/0.7.10-staticpost.txt
patching file src/http/modules/ngx_http_static_module.c
root@local:/usr/src/build/nginx-0.7.10# patch -p0 <
…/nginx-patches/0.7.10-dirtest.txt
patching file src/http/modules/ngx_http_index_module.c
On Sun, Aug 17, 2008 at 12:50:54AM -0700, mike wrote:
fastcgi auth(static locations)
fastcgi
}okay, so which out of these is the most efficient method? Maybe our
language barrier is confusing me but I am not sure which method you
are recommending or are saying is fixed/not fixed/the proper way…
The more effective is second method (using ^~).
The inclusive patch fixes all threee above configuration.
If you look at configuration schema
location ??? /wordpress/wp-admin {
(1)
location ~ \.php$ {
(2)
}
}
location ~ \.php$ {
(3)
}
then without the patch a request /wordpress/wp-admin/some.php
*) will be handled as (1) if you replace “???” with “^~”,
*) will be handled as (3) if you replace “???” with “~”,
*) will be handled as (3) if you omit “???” at all.
The patch force to handle the request in (2) always.
On 8/17/08, Igor S. [email protected] wrote:
The more effective is second method (using ^~).
The inclusive patch fixes all threee above configuration.
Excellent!
I’ve applied the 3 patches, put it into production, all seems to be
operating properly. I’m excited for 0.7.11 now
I’ve also reposted the “best way” to do WordPress on nginx on my blog
now too:
http://michaelshadle.com/2008/08/17/nginx-wordpress-redux/
Thanks for being patient