This works!
Although this still requires an extra line for each new location,
which might be forgotten by a collaborator, but this configuration
is definitely viable.
Thanks a lot!
On Wed, 12 Oct 2022 at 15:44, Maxim Dounin <mdou...@mdounin.ru> wrote:
> Hello!
>
> On Wed, Oct 12, 2022 at 11:04:50AM +0200, Anders Nicolaisen via
> nginx-devel wrote:
>
> > 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.
>
> Sure, details of the X-Accel-Redirect semantics is different from
> the one provided by auth_request.
>
> If you prefer auth_request semantics, you can do the same with
> auth_request and appropriate handling of the 403 errors, for
> example (assuming the auth backend cannot be modified and returns
> 429):
>
> server {
> listen 8080;
>
> location / {
> auth_request /auth;
> error_page 403 = /error;
> proxy_pass ...
> }
>
> location = /auth {
> error_page 429 = /limit;
> proxy_intercept_errors on;
> proxy_pass http://127.0.0.1:8081;
> }
>
> location = /limit {
> set $limit 1;
> return 403;
> }
>
> location = /error {
> if ($limit) {
> return 429;
> }
> return 403;
> }
> }
>
> server {
> listen 8081;
>
> # an example X-Accel-Redirect server
> # which rejects requests with 'foo' header set to a true
> # value
>
> if ($http_foo) {
> return 429;
> }
>
> return 204;
> }
>
> The general issue with "having auth_request be able to relay this
> one more status code" as I see it is that it's not just one status
> code. For example, request limiting in nginx by default uses 503
> status code, and it is not clear why 429 handling should be
> different. Further, there is the Retry-After header field, which
> is optional, though may appear in both 429 and 503 responses.
> Further, there are other temporary conditions which might be
> considered, such as 413 (with Retry-After) or 502/504 errors.
> Trying to extend auth_reqest to handle unrelated response codes is
> going to result in a lot of additional logic there, which is not
> needed in most configurations and will complicate things. And
> this is something I would prefer to avoid, especially given that
> the desired handling can be easily implemented simply by writing
> an appropriate configuration.
>
> > 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.
>
> In named locations there are no location prefix to replace with
> the URI part specified in proxy_pass, so you should use proxy_pass
> without URI part, that is, "proxy_pass http://localhost:8888;";,
> note no "/" at the end.
>
> See here for details:
>
> http://nginx.org/r/proxy_pass
>
> Hope this helps.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-devel mailing list -- nginx-devel@nginx.org
> To unsubscribe send an email to nginx-devel-le...@nginx.org
>
_______________________________________________
nginx-devel mailing list -- nginx-devel@nginx.org
To unsubscribe send an email to nginx-devel-le...@nginx.org
