Suppose before forwarding the data POSTed to your application you want to do certain checks on the data so that you can be sure that your application receives only the clean refined data to operate upon. (...) So your application layer can focus on working upon it without worrying about cleansing it first.
I would think that dealing with incorrect data should be handled by the application rather than nginx. If you want to expose your application via other means it means you don't have to duplicate your validation logic. Think also about giving feedback about the incorrect POST-data, I think your application is better suited to provide that, as it can return a <form> with carefully placed messages for instance.
This makes OpenResty a nice tool for operations/security, because you have enough control to implement workarounds when required without having to wait for external entities. Some of you may cringe at the notion of implementing workarounds, but that's standard practice in any corporate setting. The alternative is just worse and you learn to live with it by calling it "application firewalls".
The other nice thing about OpenResty is the flexibility gained from separating scaling/infrastructure logic from application logic. And this got even better in the last relase of the Lua module by allowing custom balancing logic in upstream blocks without having to hook into header_filter_by_lua or something like that to manipulate the URL to feed into proxy_pass.
Finally, there's microservice (or microapplication) architectures, where your big application is really a bunch of smaller applications being glued together by logic in nginx (something like Edge Side Includes but nicer).
A good chunk of traffic is bot exploit traffic and rejecting that silently at the proxy level is a viable option [its basically what Cloudflare, among others, use OpenResty for].
Incorrect data should go to the application, malicious data should be dropped before it gets there if practical.
>as it can return a <form> with carefully placed messages for instance.
Openresty can also do that. The choice may vary from person to person. But the point I was trying to make was that if I have to use nginx I'd rather use openresty. And if I use openresty I'd probably do all little tasks like validation at the proxy level itself.
I had an idea for microservice deployments: to send all incoming requests through an authenticator script, that will verify request tokens with the auth-server, and extract the user's context to some other request parameter (e.g. custom header). The benefit would be that all microservices no longer need to worry about the authorisation of incoming requests, as this is abstracted away to nginx. In this way we know that if a request reaches the target service, it has already been authorised, thus simplifying the services and removing the dependency on the auth-server, and decreasing the burden of testing these services. It works nicely.
The (very rough) script is here: https://gist.github.com/rahilb/73362f663a028f1f986c
Since a few weeks ago Openresty also has "..._by_lua_block" directives that allow you to just write some lua straight into the config without having to escape the lua code:
https://github.com/openresty/lua-nginx-module#synopsis
A more comprehensive guide: https://openresty.org/download/agentzh-nginx-tutorials-en.ht...
Edit: and it's fast as all get-out, I might add.
My employer sells an authorization and access control engine that can be queried by simple REST calls. We produced a small lua module that makes it simple to use from an `_by_lua_` directive.
Our customers (and internal teams) love it -- for the most part they use it to provide basic access control to simple web services, but some have done really sophisticated things things, such as deciding what privileges an HTTP request requires based on the body, query parameters, method, and headers.
HTTP clients can simply provide an authentication token issued by our services in a header, and everything works like magic.
At some point we were considering writing our own nginx module, and while we have the engineering talent to pull this off, OpenResty is just so much simpler, so it won the day hands down.
