Thanks!
This does make sense, and one might be able to create a somewhat working
example using this.
However, this seems to introduce a couple of drawbacks, and kind of
breaks the semantics of the 'auth_request'.
Let me illustrate:
First of all, having auth_request in the server context guards against
any newly added locations that might yet be missing rules handled
by the authentication server.
So, whenever a new location is added, the authentication server needs
to be updated as well before any requests can be redirected.
This will most often actually be a good thing in an environment with
a lot of rules and multiple developers.
Second, if multiple developers are editing the configurations, they are
not required to remember the 'internal' in order to bar these from
outsiders,
as this would be automatically imposed via auth_request.
It seems to be more in line with the current semantics of auth_request,
and also by far cleaner code/configurations, by having auth_request be
able to relay this one more status code.
P.S.:
I tried to test your suggestion with this simple conf:
-----
server {
location / {
proxy_pass http://localhost:8888/auth;
}
location @content {
proxy_pass http://localhost:8888/;
}
}
----
And got this error:
===
2022/10/12 08:51:09 [emerg] 1451#1451: "proxy_pass" cannot have URI part in
location given by regular expression, or inside named location, or inside
"if" statement, or inside "limit_except" block
===
I'm guessing I just did something wrong, but the error message seems to
tell me that it is
not possible to do it this way.
_______________________________________________
nginx-devel mailing list -- nginx-devel@nginx.org
To unsubscribe send an email to nginx-devel-le...@nginx.org
