feat: implement coraza_rules_add and coraza_rules_add_file #27
Conversation
There was a problem hiding this comment.
As Coraza v3 had many significant API changes, it looks like libcoraza C ABI needs to be updated to match it better. Rather than trying to keep the existing one using internal mechanisms, it could be updated to something like
//export coraza_new_waf_config - points to a WAFConfig
//export coraza_waf_config_add_rule - works on WAFConfig, and any other config knobs should be exposed
//export coraza_new_waf - accepts WAFConfig and returns a fully initialized WAF
How can I find the API documentation for Coraza v3? |
|
The best place to look is probably the Go pkg docs |
|
If the coraza_waf_config_add_rule returns a config, we can't add/remove rule dynamically in anytime. |
|
Coraza v3 currently doesn't support dynamic rule updates so it should be OK to remove support in connectors as well at least for now. Adding back, we could discuss in coraza repo that real-world use cases and whether dynamic updates are the best option, vs e.g. recreating waf instance etc. I think for now the primary goal of this repo should be to get updated to expose the current coraza v3. |
If I use those api , how should I do that add/remove rule dynamically in anytime? In apisix, we must implement add rule in other phase not init_by_lua phrase. |
|
Perhaps it can be a lazy singleton that's initialized once in the phase you need to? It sounds like an issue of how / when to initialize the WAF as a whole, not individual rules dynamically. |
|
recreating waf isn't acceptable. real-world case https://blog.openresty.com/en/edge-enable-waf/ 
|
Rules shouldn't be getting updated in a high traffic manner, there's a UI or API that may be used sometimes for it - it should be acceptable to reinitialize when a configuration update happens, right? This is a pretty common paradigm I think. There's far more to WAF config than rules, so if we really wanted to support dynamic updates, it would be a larger API adjustment to Coraza, which would need to be understood vs the option of just reinitializing the WAF. |
|
libcoraza can’t be portable to openresty/nginx if not reconstruct the api. Restarting nginx may cause a disruption. Should i recreate a repo that is named libcoraza-nginx ? |
|
Yeah it seems that currently the goal is to implement nginx logic with coraza rather than create a generically usable C library exposing Coraza - having a separate repo, and then going wild with whatever ABI is required, including things like the string wrapping, will be feasible. What do you think @jcchavezs? |
|
Yeah it makes sense @anuraaga. Writing a general purpose library is tough and requires experience, currently all this changes albeit legit and beneficial are biased towards openresty so my suggestion would be to make something work for openresty, nginx and Apache and then come up with food abstractions. |
No description provided.