<div dir="ltr">This works!<br><br>Although this still requires an extra line for each new location, <br>which might be forgotten by a collaborator, but this configuration<br>is definitely viable.<br><br>Thanks a lot!<br><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 12 Oct 2022 at 15:44, Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>
<br>
On Wed, Oct 12, 2022 at 11:04:50AM +0200, Anders Nicolaisen via nginx-devel wrote:<br>
<br>
> Thanks!<br>
> This does make sense, and one might be able to create a somewhat working<br>
> example using this.<br>
> <br>
> However, this seems to introduce a couple of drawbacks, and kind of<br>
> breaks the semantics of the 'auth_request'.<br>
> <br>
> Let me illustrate:<br>
> <br>
> First of all, having auth_request in the server context guards against<br>
> any newly added locations that might yet be missing rules handled<br>
> by the authentication server.<br>
> So, whenever a new location is added, the authentication server needs<br>
> to be updated as well before any requests can be redirected.<br>
> This will most often actually be a good thing in an environment with<br>
> a lot of rules and multiple developers.<br>
> <br>
> Second, if multiple developers are editing the configurations, they are<br>
> not required to remember the 'internal' in order to bar these from<br>
> outsiders,<br>
> as this would be automatically imposed via auth_request.<br>
> <br>
> It seems to be more in line with the current semantics of auth_request,<br>
> and also by far cleaner code/configurations, by having auth_request be<br>
> able to relay this one more status code.<br>
<br>
Sure, details of the X-Accel-Redirect semantics is different from <br>
the one provided by auth_request.<br>
<br>
If you prefer auth_request semantics, you can do the same with <br>
auth_request and appropriate handling of the 403 errors, for <br>
example (assuming the auth backend cannot be modified and returns <br>
429):<br>
<br>
server {<br>
   listen 8080;<br>
<br>
   location / {<br>
       auth_request /auth;<br>
       error_page 403 = /error;<br>
       proxy_pass ...<br>
   }<br>
<br>
   location = /auth {<br>
       error_page 429 = /limit;<br>
       proxy_intercept_errors on;<br>
       proxy_pass <a href="http://127.0.0.1:8081" rel="noreferrer" target="_blank">http://127.0.0.1:8081</a>;<br>
   }<br>
<br>
   location = /limit {<br>
       set $limit 1;<br>
       return 403;<br>
   }<br>
<br>
   location = /error {<br>
       if ($limit) {<br>
           return 429;<br>
       }<br>
       return 403;<br>
   }<br>
}<br>
<br>
server {<br>
   listen 8081;<br>
<br>
   # an example X-Accel-Redirect server<br>
   # which rejects requests with 'foo' header set to a true<br>
   # value<br>
<br>
   if ($http_foo) {<br>
       return 429;<br>
   }<br>
<br>
   return 204;<br>
}<br>
<br>
The general issue with "having auth_request be able to relay this <br>
one more status code" as I see it is that it's not just one status <br>
code.  For example, request limiting in nginx by default uses 503 <br>
status code, and it is not clear why 429 handling should be <br>
different.  Further, there is the Retry-After header field, which <br>
is optional, though may appear in both 429 and 503 responses.  <br>
Further, there are other temporary conditions which might be <br>
considered, such as 413 (with Retry-After) or 502/504 errors.  <br>
Trying to extend auth_reqest to handle unrelated response codes is <br>
going to result in a lot of additional logic there, which is not <br>
needed in most configurations and will complicate things.  And <br>
this is something I would prefer to avoid, especially given that <br>
the desired handling can be easily implemented simply by writing <br>
an appropriate configuration.<br>
<br>
> P.S.:<br>
> I tried to test your suggestion with this simple conf:<br>
> -----<br>
> server {<br>
> <br>
>   location / {<br>
>     proxy_pass <a href="http://localhost:8888/auth" rel="noreferrer" target="_blank">http://localhost:8888/auth</a>;<br>
>   }<br>
>   location @content {<br>
>     proxy_pass <a href="http://localhost:8888/" rel="noreferrer" target="_blank">http://localhost:8888/</a>;<br>
>   }<br>
> }<br>
> ----<br>
> <br>
> And got this error:<br>
> <br>
> ===<br>
> 2022/10/12 08:51:09 [emerg] 1451#1451: "proxy_pass" cannot have URI part in<br>
> location given by regular expression, or inside named location, or inside<br>
> "if" statement, or inside "limit_except" block<br>
> ===<br>
> <br>
> I'm guessing I just did something wrong, but the error message seems to<br>
> tell me that it is<br>
> not possible to do it this way.<br>
<br>
In named locations there are no location prefix to replace with <br>
the URI part specified in proxy_pass, so you should use proxy_pass <br>
without URI part, that is, "proxy_pass <a href="http://localhost:8888" rel="noreferrer" target="_blank">http://localhost:8888</a>;", <br>
note no "/" at the end.<br>
<br>
See here for details:<br>
<br>
<a href="http://nginx.org/r/proxy_pass" rel="noreferrer" target="_blank">http://nginx.org/r/proxy_pass</a><br>
<br>
Hope this helps.<br>
<br>
-- <br>
Maxim Dounin<br>
<a href="http://mdounin.ru/" rel="noreferrer" target="_blank">http://mdounin.ru/</a><br>
_______________________________________________<br>
nginx-devel mailing list -- <a href="mailto:nginx-devel@nginx.org" target="_blank">nginx-devel@nginx.org</a><br>
To unsubscribe send an email to <a href="mailto:nginx-devel-leave@nginx.org" target="_blank">nginx-devel-leave@nginx.org</a><br>
</blockquote></div>