Igor any change auth_basic_user_file can accept the new regex stuff?


#1

i.e.:

location ~* ^/foo/private/(.*) {
alias /home/foo/web/private/$1/;
auth_basic “Restricted files”;
auth_basic_user_file /home/foo/web/private/$1/.htpasswd;
}

Thank you so much for your time and effort in nginx! Hopefully this is
pretty trivial.


#2

On Thu, Mar 12, 2009 at 10:25:14AM -0700, mike wrote:

i.e.:

location ~* ^/foo/private/(.*) {
alias /home/foo/web/private/$1/;
auth_basic “Restricted files”;
auth_basic_user_file /home/foo/web/private/$1/.htpasswd;
}

Thank you so much for your time and effort in nginx! Hopefully this is
pretty trivial.

There’s patch by Kirill A. Korinskiy in Russian mailing list, that
allows variables in auth_basic_user_file. I will look it and if it’s
good,
will include it.


#3

Yes please!

Thanks :slight_smile:


#4

On Thu, Mar 12, 2009 at 01:26:07PM -0700, mike wrote:

Yes please!

The patch.


#5

Sorry - but adds a log in nginx.log (not sure which - maybe ‘error’
maybe ‘notice’) that says /home/foo/web/.htpasswd does not exist


#6

Igor, and the original author of the patch - you guys rock. Thank you.
This actually solves a problem I tried months ago and had to write
some custom script which sucked. Now, my users can use this without
having to ask me to re-run the script.

Seems to work like a charm and it allows for infinitely deep recursion

/foo/ works
/foo/a/b/c/ works

etc.

It does suck that nginx throws a 500 internal server error when no
.htpasswd exists.

Could there be a way with this dynamic auth_basic_user_file thing that
it just issues a 403 instead of a 500?

2009/3/14 Igor S. removed_email_address@domain.invalid:


#7

On Sat, Mar 14, 2009 at 10:27:28AM -0700, mike wrote:

Sorry - but adds a log in nginx.log (not sure which - maybe ‘error’
maybe ‘notice’) that says /home/foo/web/.htpasswd does not exist

Currently it says

[crit] 52208#0: *1 open() “…” failed (2: No such file or directory)

Probably it should be lower to error level.


#8

On Sat, Mar 14, 2009 at 10:26:50AM -0700, mike wrote:

etc.

It does suck that nginx throws a 500 internal server error when no
.htpasswd exists.

Could there be a way with this dynamic auth_basic_user_file thing that
it just issues a 403 instead of a 500?

Probably 403 should be return in both cases (static and dynamic) if
error
is file not found.


#9

On Sat, Mar 14, 2009 at 11:22:06AM -0700, mike wrote:

directory), client: 192.168.1.2, server: 192.168.1.3, request: “GET
/fds HTTP/1.1”, host: “192.168.1.3”

IMHO it should be less important for a 404 :slight_smile:

The error level is done as in Apache. There is no simple way to tell
broken link from mistype/etc.


#10

correct, but why would that be an ‘error’

an ‘error’ to me is something that the server needs to be reconfigured
for. this could be simple human error. it could also require server
tweaks to make it work too, but i guess you’re right.


#11

2009/3/14 Igor S. removed_email_address@domain.invalid:

Probably 403 should be return in both cases (static and dynamic) if error
is file not found.

That is fine with me. I was going to recommend that but thought it
might be a bit incorrect. Since htpasswd stuff -is- required to be
configured on the server level, it is sort of a server error if it’s
pointing to the wrong file. However, the users can control the files a
lot of the time and remove them…

As long as there is a simple to read error log entry for it, that
works. Right now a 404 throws an “error” - shouldn’t that be more like
a “notice” ?

This missing file should be an error as it has more to do with server
configuration. But me randomly typing in /ekfhskdfdskhfs into a site
should not raise an “error” level:

2009/03/14 11:20:25 [error] 32217#0: *1 open()
“/home/mike/web/192.168.1.3/fds” failed (2: No such file or
directory), client: 192.168.1.2, server: 192.168.1.3, request: “GET
/fds HTTP/1.1”, host: “192.168.1.3”

IMHO it should be less important for a 404 :slight_smile: