Comment by adontz | Hacker News Reader

Comment by adontz | Hacker News Reader

Not to say they did anything wrong, great work! But if facing the same problem, but for inhouse solution I'd consider using auth_requrest in the first place.

https://nginx.org/en/docs/http/ngx_http_auth_request_module....

To me, advantage is archtectural, that I would not have specify which parameters of request are considered or how are they processed. Disadvantage is semantic, returning 403 instead of 429. But original article states returning 403 anyway.

And also, regarding rate limiting by IP, I think it should be done for 10x-100x of single user limit, just as first line of defense. Also nginx rate limiting has notion of burst which helps filter out "smart" crawlers, which unlike users, send requests for hours.

You can change a 403 to a 429 easily in conjunction with auth_request using a named location.

One thing I've been doing recently is to deploy oauth2_proxy in proxy mode, protecting an authorization endpoint. The authorization endpoint can be custom code in any langauge - it can have logic for rate limiting or anything else. Together oauth2_proxy handles authentication, and the authorization endpoint might do an LDAP lookup and limit access based on a group or something else. If you want to return something other than a 401 or a 403 you have to do a little more work.

Something along the lines of this:

     location / {
        auth_request /auth;
        auth_request_set $backend_status $upstream_status;
     }

     location = /auth {
          proxy_pass http://oauth2-proxy:8080/authz;
          proxy_pass_request_body off;
          proxy_set_header Content-Length "";
          proxy_set_header X-Original-URI $request_uri;
      }

     location @process_backend_error {
         return $backend_status;
     }

Reply on news.ycombinator.com