Exposing some of the hidden packages behind `internal` folder. about coraza HOT 9 OPEN

Hey! The reason behind this is long-term maintenance; if you want a specific API or set of APIs, please mention them on this issue so we can review this. We don't have any problem with exposing additional APIs as long as it's safe, it doesn't break compatibility, and there is a clear use case.

There are certain limitations, for example, we cannot expose additional functions for existing immutable interfaces, as it breaks compatibility. In which case we would have to release Wrappers to access to them. Like:

tx := tx.(types.TransactionState)
tx = tx.(otherpackage.TransactionExtended)

from coraza.

In my case described above I guess I would want access to:

• corazawaf.NewWAF()
• seclang.NewParser()
• parser.FromString()

from coraza.

Do you want to create a new parser, or just add some directives?

from coraza.

No, some utility that checks rules validity and has a bit more verbose error messages in regards to where the actual broken rule is (file:linenumber).

from coraza.

from coraza.

@jptosso Another solution maybe just standalone CLI utility in repository that just loads ruleset and reports error if any, I am fine with doing PRs as long as there is some kind of simplified entry point for rule testing that is.

Also this will be similar to what has libmodsecurity, they ship standalone CLI to just do rule verification.

This way there is no need to wraparound into experimental API.

from coraza.

from coraza.

@jptosso Yea, sounds also good

from coraza.

Check https://github.com/corazawaf/coraza/pull/1101/files

from coraza.