Simple auth question for nested sections

Server NGINX
1

apologies for the simple question, but i could only find the opposite
situation in the list archives and I haven’t had to reconfigure some of
these routes in years!

i have

works

location /foo {
proxy_pass http://127.0.0.1:6543;
}

I want to lock down /foo/admin with basic auth

works

location /foo/admin {
proxy_pass http://127.0.0.1:6543;
auth_basic “Administrator Login”;
auth_basic_user_file /etc/nginx/_htpasswd/well-known;
}

Is there a syntax for nesting the two together, so the /foo/admin would
inherit the /foo configuration without the need to redeclare everything?

something like

location /foo {
proxy_pass http://127.0.0.1:6543;
location /foo/admin {
auth_basic “Administrator Login”;
auth_basic_user_file /etc/nginx/_htpasswd/well-known;
}
}

2

Why would you want to do that? Spaghetti configuration?
Some advice from Igor S.: Scaleable NGINX Configuration: Igor Sysoev @nginxconf 2014 - YouTube

B. R.

3

On Tue, Mar 22, 2016 at 08:00:13PM -0400, Jonathan V. wrote:

Hi there,

Is there a syntax for nesting the two together, so the /foo/admin would inherit
the /foo configuration without the need to redeclare everything?

something like

location /foo {
proxy_pass http://127.0.0.1:6543;
location /foo/admin {
auth_basic “Administrator Login”;
auth_basic_user_file /etc/nginx/_htpasswd/well-known;
}
}

You would do it exactly as you have done it.

Any directives that inherit do not need to be repeated.

If it does not work for you, that’s probably due to proxy_pass not
inheriting.

So repeat that one, but not everything else.

If your example is your exact config, then “everything else” is
“nothing”,
and there is no immediate benefit to nesting.

f

Francis D. [email protected]

4

I guess the docs logic is reversed: it is explicitely stated when a
directive inherits, which must be that way because not considered the
default behavior (although I am not in Igor’s head…).

This product uses a different paradigm that ‘minimal configuration
lines’,
and Igor has nothing against duplicated blocks, which allow direct
understanding of what is in effect in the location block you are looking
at, compared to horizontal/similar ones (ofc server-wide directives
shall
not and won’t be redeclared at location level).
In the modern world, use of configuration management tools, which allow
templating, allows duplicated stanzas without trouble on configuration
generation/deployment.

That is a way of looking at configuration, and everyone has his/her
views
on it.
Please, correct me if I am wrong.

B. R.

5

Hello!

On Thu, Mar 24, 2016 at 06:17:44PM +0100, B.R. wrote:

I guess the docs logic is reversed: it is explicitely stated when a
directive inherits, which must be that way because not considered the
default behavior (although I am not in Igor’s head…).

No, by default all directives are inherited from previous levels.
The only exceptions are:

  • location content handlers (proxy_pass, fastcgi_pass, scgi_pass,
    uwsgi_pass, memcached_pass, empty_gif, stub_status, mp4, flv,
    perl);

  • rewrite directives (if, rewrite, break, return);

  • try_files.

In most cases this is more or less obvious when directives are not
inherited, though docs can be a bit more clear on this.

–
Maxim D.
http://nginx.org/

6

On Mar 23, 2016, at 2:14 PM, Francis D. wrote:

Any directives that inherit do not need to be repeated.

If it does not work for you, that’s probably due to proxy_pass not
inheriting.

Thanks - that’s it – proxy_pass does not inherit, but all the
proxy_set_header directives in that block do.
Only the proxy_pass directive needed to be repeated in the location
block (thank goodness!)

location /foo {
proxy_pass http://127.0.0.1:6543;
# nearly 10 lines of proxy_set_header
…
location /foo/admin {
proxy_pass http://127.0.0.1:6543;
auth_basic “Administrator Login”;
auth_basic_user_file /etc/nginx/_htpasswd/foo;
}
}

On Mar 23, 2016, at 7:20 AM, B.R. wrote:

Why would you want to do that? Spaghetti configuration?

The proxy has a dozen lines of configuration.
The proxy_pass line doesn’t inherit, but the docs don’t mention that.
Only the proxy_pass directive not inheriting was the last thing I
expected. So I had to run duplicate blocks until things worked.

7

On Mar 24, 2016, at 1:27 PM, Maxim D. wrote:

In most cases this is more or less obvious when directives are not
inherited, though docs can be a bit more clear on this.

What is not-obvious / confusing is that the *_pass items are not
inherited… but their associated directives from the same module are.

On Mar 24, 2016, at 1:17 PM, B.R. wrote:

This product uses a different paradigm that ‘minimal configuration lines’, and
Igor has nothing against duplicated blocks, which allow direct understanding of
what is in effect in the location block you are looking at, compared to
horizontal/similar ones (ofc server-wide directives shall not and won’t be
redeclared at location level).
In the modern world, use of configuration management tools, which allow
templating, allows duplicated stanzas without trouble on configuration
generation/deployment.

I’m fine with that. I’ve been using nginx for 10 years now (!) and have
a huge library of macros that are included into various blocks dozens of
times.

Right now I’m trying to open-source something I wrote to handle
lets-encrypt certificate management behind nginx.

For simplicity, I wanted to make a very concise nested block for the
documents. When there are many header variables that need to be set,
the docs can get hard for people to follow.

8

Jonathan, please read Maxim’s answer, which is the one going the right
way.
My hypothesis proved to be wrong.

B. R.

9

Thanks Maxim for your lights!

Please discard all the crap I wrote before and apologies to Jonathan,
then.
:oP

B. R.