Ruby Forum NGINX > Another auth/location question - probably very simple to fix :)

prompts but only on the exact /wordpress/admin match:

location /wordpress/admin {
   auth_basic "wordpress";
   auth_basic_user_file /home/foo/web/foo.com/.htpasswd
   location ~ \.php$ {
     fastcgi_pass 127.0.0.1:11000;
     fastcgi_index index.php;
   }
}

doesn't prompt at all:

location ~ /wordpress/admin(.+) {
   auth_basic "wordpress";
   auth_basic_user_file /home/foo/web/foo.com/.htpasswd
   location ~ \.php$ {
     fastcgi_pass 127.0.0.1:11000;
     fastcgi_index index.php;
   }
}

am i missing something? i thought i had it fully secured. not sure if
behavior changed from 0.7.4 or so to 0.7.10

i want everything under /wordpress/admin/ to require basic auth. i
could have sworn this worked properly before, but now the first one
prompts only for the / index, if i enter in a direct URL i get no
prompt (like /wordpress/admin/post-new.php)

thanks...

On Fri, Aug 15, 2008 at 05:55:05PM -0700, mike wrote:

> prompts but only on the exact /wordpress/admin match:
> 
> location /wordpress/admin {

But the better way is disable regex searches:

- location /wordpress/admin {
+ location ^~ /wordpress/admin {

On Fri, Aug 15, 2008 at 05:55:05PM -0700, mike wrote:

> 
> 
> am i missing something? i thought i had it fully secured. not sure if
> behavior changed from 0.7.4 or so to 0.7.10
> 
> i want everything under /wordpress/admin/ to require basic auth. i
> could have sworn this worked properly before, but now the first one
> prompts only for the / index, if i enter in a direct URL i get no
> prompt (like /wordpress/admin/post-new.php)

Do you have something like "location ~ \.php$" before
"location ~ /wordpress/admin(.+)" ?
If so, the former matchs "/wordpress/admin/post-new.php".

On 8/16/08, Igor Sysoev <is@rambler-co.ru> wrote:

> But the better way is disable regex searches:
>
> - location /wordpress/admin {
> + location ^~ /wordpress/admin {

that breaks the php parsing inside of wp-admin... i need PHP to still
parse inside of the protected directory, i have this inside of that
block:

location ~ \.php$ {
   fastcgi_pass 127.0.0.1:11000;
   fastcgi_index index.php;
}

On 8/16/08, Igor Sysoev <is@rambler-co.ru> wrote:

> Do you have something like "location ~ \.php$" before
> "location ~ /wordpress/admin(.+)" ?
> If so, the former matchs "/wordpress/admin/post-new.php".

yes i do, here's the entire config:


  server {
    listen 80;
    server_name foo.com;
    index index.php index.html;
    root /home/mike/web/foo.com/;
    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;
        fastcgi_index index.php;
      }
    }
    location ~ \.php$ {
      fastcgi_pass 127.0.0.1:11000;
      fastcgi_index index.php;
    }
    if (!-e $request_filename) {
      rewrite ^(.+)$ /wordpress/index.php?q=$1 last;
    }
  }

sorry i -did- have it before the location block, i also tried it
after. both work the same

On Sat, Aug 16, 2008 at 01:00:40AM -0700, mike wrote:

> 
> location ~ \.php$ {
>    fastcgi_pass 127.0.0.1:11000;
>    fastcgi_index index.php;
> }

"^~" does not disable regex for inclusive location.
It disables regex locations of the the same level only.

On Sat, Aug 16, 2008 at 01:02:51AM -0700, mike wrote:

>     listen 80;
>     }
>     location ~ \.php$ {
>       fastcgi_pass 127.0.0.1:11000;
>       fastcgi_index index.php;
>     }
>     if (!-e $request_filename) {
>       rewrite ^(.+)$ /wordpress/index.php?q=$1 last;
>     }
>   }

Apply the attached patch that allows POST for non-existent static files
and try the following configuration:

    server {
        listen 80;
        server_name foo.com;
        index index.php index.html;
        root /home/mike/web/foo.com/;

        error_page 404 = /wordpress/index.php?q=$request_uri;

        location / {
        }

        location ^~ /wordpress/admin {

            auth stuff

            location ~ \.php$ {
                 fastcgi_pass 127.0.0.1:11000;
                 # fastcgi_index is not needed here
            }
        }

        location ~ \.php$ {
            fastcgi_pass 127.0.0.1:11000;
            # fastcgi_index is not needed here
            }
        }
    }

On 8/16/08, Igor Sysoev <is@rambler-co.ru> wrote:

> "^~" does not disable regex for inclusive location.
> It disables regex locations of the the same level only.

okay, so how would you write out that server block so that php works
in both normal and in admin, and admin is behind basic auth?

Sorry - replied too quickly.

I am interested in updating to the latest 0.7.10 but I also am relying
on the directory index behavior patch that Maxim wrote too. I will try
to compile nginx now with the attached patch + that patch.

patch-nginx-dirtest.txt (maxim's patch)
and this patch

wasn't patch-not-found.txt merged into .9 or .10?

(BTW, it works right now even without the patch but probably not for
commenting or anything submitting a form via POST)

On Sat, Aug 16, 2008 at 01:31:56AM -0700, mike wrote:

> Sorry - replied too quickly.
> 
> I am interested in updating to the latest 0.7.10 but I also am relying
> on the directory index behavior patch that Maxim wrote too. I will try
> to compile nginx now with the attached patch + that patch.
> 
> patch-nginx-dirtest.txt (maxim's patch)
> and this patch
> 
> wasn't patch-not-found.txt merged into .9 or .10?

What patch do you mean ?

> (BTW, it works right now even without the patch but probably not for
> commenting or anything submitting a form via POST)

GET worked long ago. The patch for POST only.

On 8/16/08, Igor Sysoev <is@rambler-co.ru> wrote:

> What patch do you mean ?

Ideally all three of these patches to work in 0.7.10:

1) http://marc.info/?l=nginx&m=121871958203885&w=2 -
2) http://marc.info/?l=nginx&m=121818872305549&w=2 - applies
3) and the static post patch you just supplied - it applies with fuzz

(I apply these using patch -p1 < patch.txt, let me know if there is a
better way)

> GET worked long ago. The patch for POST only.

understood

On Sat, Aug 16, 2008 at 01:48:22AM -0700, mike wrote:

> (I apply these using patch -p1 < patch.txt, let me know if there is a
> better way)

1) and 3) are the same slightly different patch. Use the 3) only.
it will be in 0.7.11 certainly.

2) will probably be 0.7.11 too. Additional syscalls should be 
compensated
by "open_file_cache_errors  on".

Okay, I applied two patches and that same config that was working in
0.7.8 and wordpress admin is back to not parsing PHP...



root@local:/usr/src/build/nginx-0.7.10# patch -p1 <
../nginx-patches/0.7.10-staticpost.txt
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: src/http/modules/ngx_http_static_module.c
|===================================================================
|--- src/http/modules/ngx_http_static_module.c  (revision 1500)
|+++ src/http/modules/ngx_http_static_module.c  (working copy)
--------------------------
File to patch: src/http/modules/ngx_http_static_module.c
patching file src/http/modules/ngx_http_static_module.c


root@local:/usr/src/build/nginx-0.7.10# patch -p1 <
../nginx-patches/0.7.8-dirtest.txt
patching file src/http/modules/ngx_http_index_module.c
Hunk #1 succeeded at 309 with fuzz 1.
root@local:/usr/src/build/nginx-0.7.10#

On 8/16/08, Igor Sysoev <is@rambler-co.ru> wrote:

> > 1) http://marc.info/?l=nginx&m=121871958203885&w=2 -
> > 2) http://marc.info/?l=nginx&m=121818872305549&w=2 - applies
> > 3) and the static post patch you just supplied - it applies with fuzz
> >
> > (I apply these using patch -p1 < patch.txt, let me know if there is a
> > better way)
>
> 1) and 3) are the same slightly different patch. Use the 3) only.
> it will be in 0.7.11 certainly.

okay. that's what i did this time.

> 2) will probably be 0.7.11 too. Additional syscalls should be compensated
> by "open_file_cache_errors  on".

so I will want to say this, or other people who are worried about the
additional syscalls by cycling through the index files will want to
turn it on?

remember I am advocating testing all the index file options until they 
run out.

On Sat, Aug 16, 2008 at 02:06:15AM -0700, mike wrote:

> > it will be in 0.7.11 certainly.
> remember I am advocating testing all the index file options until they run out.
You may set it on, it can be turned on/off on http/server/location 
levels.
I usually set it off for mirror-on-demand locations:

        location /dir/ {
            open_file_cache_errors  off;
            error_page  404 = @fetch;
        }

        location @fetch {
            proxy_store  on;
            ...
        }

On 8/16/08, Igor Sysoev <is@rambler-co.ru> wrote:
> > 3) and the static post patch you just supplied - it applies with fuzz
> >
> > (I apply these using patch -p1 < patch.txt, let me know if there is a
> > better way)
>
> 1) and 3) are the same slightly different patch. Use the 3) only.
> it will be in 0.7.11 certainly.
>
> 2) will probably be 0.7.11 too. Additional syscalls should be compensated
> by "open_file_cache_errors  on".

okay, now i haven't changed my config, but i am getting prompted to
download/PHP is not parsing for both 0.7.8 and 0.7.10!

so now my PHP is not being parsed inside of the admin location block
at all... and i'm using my original 0.7.8 with the two patches i
already had on it. i don't know how this has happened now.



and i want to ask a clarification: will maxim's patch be adopted
as-is, and if people don't like that behavior they have the option to
set the open_file_cache_errors option? i am trying to figure out if it
will behave how i want by default, or if i am the one that needs to
make a config change :)

yeah i've tried a vanilla 0.7.8 with maxim's patch and it still isn't
processing PHP inside of that nested location block for admin.

something is messed up. before it was working it looked like. but now
i can't get any 0.7.8 or 0.7.10 with any patches to process that admin
block properly!

okay i've fixed it.

currently running 0.7.10 with maxim's dirlist patch (had some fuzz)
and your static post patch.

config is:

       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;
                }
        }

apparently the regex i tried earlier for admin was wrong. i had the
right idea though.

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 :)

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 Sat, Aug 16, 2008 at 02:43:00AM -0700, mike wrote:

> and i want to ask a clarification: will maxim's patch be adopted
> as-is, and if people don't like that behavior they have the option to
> set the open_file_cache_errors option? i am trying to figure out if it
> will behave how i want by default, or if i am the one that needs to
> make a config change :)

No, open_file_cache_errors has not direct relatin to index files.
It simply way to decrease number of syscalls using cache while testing
index files.

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 ?

On 8/16/08, Igor Sysoev <is@rambler-co.ru> 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 8/16/08, Igor Sysoev <is@rambler-co.ru> 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 Sysoev <is@rambler-co.ru> 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: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 12:39:13PM -0700, mike wrote:

> On 8/16/08, Igor Sysoev <is@rambler-co.ru> 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 Sysoev <is@rambler-co.ru> 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 11:29:54PM +0400, Igor Sysoev 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 Sysoev 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.

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 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:

http://wiki.codemongers.com/NginxHttpCoreModule#location

On Sat, Aug 16, 2008 at 2:46 PM, Igor Sysoev <is@rambler-co.ru> wrote:

> It matters for regex only:
>
> http://wiki.codemongers.com/NginxHttpCoreModule#location

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!

On Sat, Aug 16, 2008 at 1:07 PM, Igor Sysoev <is@rambler-co.ru> 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 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 8/16/08, Igor Sysoev <is@rambler-co.ru> 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 Sun, Aug 17, 2008 at 12:19:50AM -0700, mike wrote:

> >    location ~ /wordpress/wp-admin/.*\.php$ {
> 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?

The three following configuration do not work without the patch:

(yours with regex)

   location ~ /wordpress/wp-admin {
       auth

       location ~ \.php$ {
          fastcgi
       }
   }

   location ~ \.php$ {
      fastcgi
   }

(disable regex ^~)

   location ^~ /wordpress/wp-admin {
       auth

       location ~ \.php$ {
          fastcgi
       }
   }

   location ~ \.php$ {
      fastcgi
   }

(static locations)

   location /wordpress/wp-admin {
       auth

       location ~ \.php$ {
          fastcgi
       }
   }

   location ~ \.php$ {
      fastcgi
   }

On 8/17/08, Igor Sysoev <is@rambler-co.ru> wrote:

>   }
>       location ~ \.php$ {
>   location /wordpress/wp-admin {
>       auth
>
>       location ~ \.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 Sysoev <is@rambler-co.ru> 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 :)

Bonjour,

I'm trying to run the admin postfixadmin, I use nginx 0.6.32.

With this:

location ^~  /postfixadmin/admin {
    auth_basic            "Restricted";
    auth_basic_user_file  /usr/local/nginx/conf/htpasswd;
    location ~ \.php$ {
    fastcgi_pass   unix:/dev/shm/php2.socket;}
}

After retracted the login / pass, I have this:

The page you are looking for is temporarily unavailable.
Please try again later.

2008/08/17 17:47:04 [error] 32735#0: *144 recv() failed (104: Connection 
reset by peer) while reading response header from upstream, client: 
8.6.11.14, server: 212.3.20.6, request: "GET 
/postfixadmin/admin/index.php HTTP/1.1", upstream: 
"fastcgi://unix:/dev/shm/php2.socket:", host: "vigi.net"

2008/08/17 17:47:04 [error] 32735#0: *144 recv() failed (104: Connection 
reset by peer) while reading response header from upstream, client: 
8.6.11.14, server: 212.3.20.6, request: "GET 
/postfixadmin/admin/index.php HTTP/1.1", upstream: 
"fastcgi://unix:/dev/shm/php2.socket:", host: "vigi.net"


With that:


location ~  /postfixadmin/admin/.*\.php$ {
    auth_basic            "Restricted";
    auth_basic_user_file  /usr/local/nginx/conf/htpasswd;
    fastcgi_pass   unix:/dev/shm/php2.socket;}

Even result.


Other test:

location ~  /postfixadmin/admin/.*\.php$ {
    auth_basic            "Restricted";
    auth_basic_user_file  /usr/local/nginx/conf/htpasswd;
    location ~ \.php$ {
    fastcgi_pass   unix:/dev/shm/php2.socket;}}

Résultat => http://img205.imageshack.us/img205/963/adminky5.png

Avec:

location  ^~  /postfixadmin/admin {
    auth_basic            "Restricted";
    auth_basic_user_file  /usr/local/nginx/conf/htpasswd;
    location ~ \.php$ {
    fastcgi_pass   unix:/dev/shm/php2.socket;}}

2008/08/17 17:59:18 [error] 553#0: *63 recv() failed (104: Connection 
reset by peer) while reading response header from upstream, client: 
82.7.11.104, server: 22.4.22.6, request: "GET 
/postfixadmin/admin/index.php HTTP/1.1", upstream: 
"fastcgi://unix:/dev/shm/php2.socket:", host: "vigi.net"

2008/08/17 17:59:19 [error] 553#0: *63 recv() failed (104: Connection 
reset by peer) while reading response header from upstream, client: 
8.67.11.104, server: 22.4.22.6, request: "GET 
/postfixadmin/admin/index.php HTTP/1.1", upstream: 
"fastcgi://unix:/dev/shm/php2.socket:", host: "vigi.net"

I do not understand :|

On Sun, Aug 17, 2008 at 05:55:34PM +0200, Mikel Arteta wrote:

> 
> 
> 2008/08/17 17:47:04 [error] 32735#0: *144 recv() failed (104: Connection 
> reset by peer) while reading response header from upstream, client: 
> 8.6.11.14, server: 212.3.20.6, request: "GET 
> /postfixadmin/admin/index.php HTTP/1.1", upstream: 
> "fastcgi://unix:/dev/shm/php2.socket:", host: "vigi.net"

This is some problem with backend. Try to use TCP.

> This is some problem with backend. Try to use TCP.

I have the same result:

location    /postfixadmin/admin {
    auth_basic            "Restricted";
    auth_basic_user_file  /usr/local/nginx/conf/htpasswd;
  location ~ \.php$ {
    fastcgi_pass   localhost:9000;
    fastcgi_param  SCRIPT_FILENAME 
/data/www/postfixadmin/admin$fastcgi_script_name;}}

2008/08/17 18:57:56 [error] 2351#0: *13 recv() failed (104: Connection 
reset by peer) while reading response header from upstream, client: 
8.7.11.04, server: 22.4.22.6, request: "GET /postfixadmin/admin/ 
HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "vigi.net"

2008/08/17 18:57:57 [error] 2351#0: *13 recv() failed (104: Connection 
reset by peer) while reading response header from upstream, client: 
8.7.11.14, server: 22.3.20.6, request: "GET /postfixadmin/admin/ 
HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "vigi.net"

On Sun, Aug 17, 2008 at 06:53:45PM +0200, Mikel Arteta wrote:

> /data/www/postfixadmin/admin$fastcgi_script_name;}}
> 
> 2008/08/17 18:57:56 [error] 2351#0: *13 recv() failed (104: Connection 
> reset by peer) while reading response header from upstream, client: 
> 8.7.11.04, server: 22.4.22.6, request: "GET /postfixadmin/admin/ 
> HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "vigi.net"
> 
> 2008/08/17 18:57:57 [error] 2351#0: *13 recv() failed (104: Connection 
> reset by peer) while reading response header from upstream, client: 
> 8.7.11.14, server: 22.3.20.6, request: "GET /postfixadmin/admin/ 
> HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "vigi.net"

Something wrong with backend: for some reason it resets connection 
instead
of response.

This works with version 0.7.10, With the same configuration.

Do you know why ?

Mikel Arteta wrote:
> This works with version 0.7.10, With the same configuration.
> 
> Do you know why ?
Indeed not.

With this:

location    /postfixadmin/admin {
    auth_basic            "Restricted";
    auth_basic_user_file  /usr/local/nginx/conf/htpasswd;

 location ~ \.php$ {
    fastcgi_pass   localhost:9000;
    fastcgi_param  SCRIPT_FILENAME 
/data/www/postfixadmin/admin$fastcgi_script_name;}}


It works, but just for url "http://domain.fr/postfixadmin/admin" if you 
put "/ postfixadmin/admin/list-admin.php", more word passes, which is 
normal with this configuration.

avec: location  ^~  /postfixadmin/admin {
=> http://img205.imageshack.us/img205/963/adminky5.png

On Sun, Aug 17, 2008 at 07:29:43PM +0200, Mikel Arteta wrote:

>     auth_basic_user_file  /usr/local/nginx/conf/htpasswd;
> 
> avec: location  ^~  /postfixadmin/admin {
> => http://img205.imageshack.us/img205/963/adminky5.png

This is bug in 0.7.x - it does not pass request to fastcgi in this
configuration, so you do not see reset connection.
The attached patch fixes the bug.

BTW, what is "avec" - in/with ?

Igor Sysoev wrote:
> BTW, what is "avec" - in/with ?
Du francais :) avec<=>with

Well, with the path that goes well, but I always have the error php-fpm.

location ^~   /postfixadmin/admin/  {
    auth_basic            "Restricted";
    auth_basic_user_file  /usr/local/nginx/conf/htpasswd;
    location ~ \.php$ {
   fastcgi_pass   unix:/dev/shm/php2.socket;}}

The page you are looking for is temporarily unavailable.
Please try again later.

2008/08/17 20:17:56 [error] 9456#0: *66 recv() failed (104: Connection 
reset by peer) while reading response header from upstream, client: 
82.6.11.104, server: 21.4.22.6, request: "GET 
/postfixadmin/admin/list-admin.php HTTP/1.1", upstream: 
"fastcgi://unix:/dev/shm/php2.socket:", host: "vigi.net"

2008/08/17 20:17:56 [error] 9456#0: *66 recv() failed (104: Connection 
reset by peer) while reading response header from upstream, client: 
8.7.111.14, server: 21.4.20.6, request: "GET 
/postfixadmin/admin/list-admin.php HTTP/1.1", upstream: 
"fastcgi://unix:/dev/shm/php2.socket:", host: "vigi.net"

I not understand this error php-fpm.

On Sun, Aug 17, 2008 at 08:17:09PM +0200, Mikel Arteta wrote:

>    fastcgi_pass   unix:/dev/shm/php2.socket;}}
> 2008/08/17 20:17:56 [error] 9456#0: *66 recv() failed (104: Connection 
> reset by peer) while reading response header from upstream, client: 
> 8.7.111.14, server: 21.4.20.6, request: "GET 
> /postfixadmin/admin/list-admin.php HTTP/1.1", upstream: 
> "fastcgi://unix:/dev/shm/php2.socket:", host: "vigi.net"
> 
> I not understand this error php-fpm.

This is backend error and probably php-fpm related, try to ask in
http://groups.google.com/group/highload-php-en

On 8/17/08, Igor Sysoev <is@rambler-co.ru> wrote:

> This is backend error and probably php-fpm related, try to ask in
> http://groups.google.com/group/highload-php-en

I use php-fpm with 5.2.6 right now - no problem whatsoever. using TCP.

in fact, it's been better with nginx + php-fpm, before I was having
random 500 bad gateway issues with zeus and could not debug it since
it was closed source...

I'd recommend upgrading to the latest everything :)