My module is overriding the rate limiting module status for POST requests.

Maxim Dounin mdounin at mdounin.ru
Sun Dec 4 19:49:05 UTC 2022


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/



More information about the nginx mailing list