Hello!

On Sun, Dec 04, 2022 at 04:57:17PM +0000, Jeremy Cocks via nginx wrote:

> I am developing an AuthZ module.

[...]

> Setting my module to run in the `precontent` phase allows this to work, so
> it's all happening in rewrite (where the rate limiting module would be
> kicking in).
>
> I obviously don't want to run in precontent and my module gets its
> advice from an external "agent" as to what to set the status. So I'm
> assuming it is overwriting the nginx rate limiting module's status and
> setting it back to a 200, when I'd rather respect the rate limiting modules
> 429.
>
> What would be the best approach here to avoid this from happening? I have
> read about module ordering, but that would require a recompile of my end,
> however, I am more intrigued about how to handle this in code.

Auth modules are expected to work at the access phase
(NGX_HTTP_ACCESS_PHASE), so these can be combined by using the
"satisfy" directive (http://nginx.org/r/satisfy), and won't
interfere with request limiting, which happens just before the
access phase, at the preaccess phase (NGX_HTTP_PREACCESS_PHASE).

In particular, such order ensures that rate limiting is able to
protect auth modules from bruteforce attacks.

It also ensures that you don't need to think about any overwriting
and or anything like this - requests which do not satisfy rate
limits configured will be rejected before the control reaches the
access phase.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx mailing list -- nginx@nginx.org
To unsubscribe send an email to nginx-leave@nginx.org