Another auth/location question - probably very simple to fix :)

Server NGINX
#1

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…

#2

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 {
#3

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”.

#4

On 8/16/08, Igor S. [email protected] 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;
}

#5

On 8/16/08, Igor S. [email protected] 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;
}
}

#6

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

#7

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.

#8

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
        }
    }
}
#9

On 8/16/08, Igor S. [email protected] 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?

#10

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.

#11

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)

#12

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”.

#13

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…

[email protected]:/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

[email protected]:/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.
[email protected]:/usr/src/build/nginx-0.7.10#

#14

On 8/16/08, Igor S. [email protected] 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

#15

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;
        ...
    }
#16

On 8/16/08, Igor S. [email protected] wrote:

  1. 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 :slight_smile:

#17

On 8/16/08, Igor S. [email protected] 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.

  1. 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.

#18

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

#19

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!

#20

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

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 ?