Forum: NGINX Igor any change auth_basic_user_file can accept the new regex stuff?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
mike (Guest)
on 2009-03-12 19:38
(Received via mailing list)
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.
Igor S. (Guest)
on 2009-03-12 22:26
(Received via mailing list)
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.
mike (Guest)
on 2009-03-12 22:33
(Received via mailing list)
Yes please!

Thanks :)
Igor S. (Guest)
on 2009-03-14 19:10
(Received via mailing list)
Attachment: patch.user_file (0 Bytes)
On Thu, Mar 12, 2009 at 01:26:07PM -0700, mike wrote:

> Yes please!

The patch.
mike (Guest)
on 2009-03-14 19:35
(Received via mailing list)
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>:
mike (Guest)
on 2009-03-14 19:35
(Received via mailing list)
Sorry - but adds a log in nginx.log (not sure which - maybe 'error'
maybe 'notice') that says /home/foo/web/.htpasswd does not exist
Igor S. (Guest)
on 2009-03-14 20:01
(Received via mailing list)
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.
Igor S. (Guest)
on 2009-03-14 20:11
(Received via mailing list)
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.
mike (Guest)
on 2009-03-14 20:32
(Received via mailing list)
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 :)
Igor S. (Guest)
on 2009-03-14 21:59
(Received via mailing list)
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 :)

The error level is done as in Apache. There is no simple way to tell
broken link from mistype/etc.
mike (Guest)
on 2009-03-14 22:38
(Received via mailing list)
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.
This topic is locked and can not be replied to.