-
-
Notifications
You must be signed in to change notification settings - Fork 234
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make Waf truly immutable #371
Comments
The problem with this change is that we would be required to rename the seclang project into config, and use the config package to create the coraza.NewWafWithConfig() Other problem we might face is that connectors can actually replace the *Waf pointer to "reload" rules |
I am going to dedicate next week to prototyping on this. For context, my expectation is to use seclang, while likely moving it to internal as an implementation detail of configuration. But will look at this more.
Generally I have seen dynamic reload to have access to all configuration so should be able to create a new immutable WAF. If finding cases of small tweaks, we can at that point support recreating a still immutable WAF I think |
The other problem we might face is how to handle seclang as an independent package. coraza package cannot consume seclang as it would create circular dependencies issues. Maybe we should use the seclang package to send config.WithRule(*coraza.Rule) to the waf instance. That way waf would still be abstracted from seclang. |
Currently Waf is implied to be immutable with a doc
https://github.com/corazawaf/coraza/blob/v3/dev/waf.go#L43
Docs can be easily missed, especially in code that is not creating the Waf itself. I think it would be a good idea to make the code itself immutable. It will be a significant refactoring, but it could be worth doing to make the experience more safe for users, and to make it easier for coraza developers to reason about the code being safe.
The text was updated successfully, but these errors were encountered: