-
Notifications
You must be signed in to change notification settings - Fork 429
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
Allow custom "metadata" in decisions #2922
Comments
@blotus: Thanks for opening an issue, it is currently awaiting triage. In the meantime, you can:
DetailsI am a bot created to help the crowdsecurity developers manage community feedback and contributions. You can check out my manifest file to understand my behavior and what I can do. If you want to use this for your project, you can check out the BirthdayResearch/oss-governance-bot repository. |
@blotus: There are no 'kind' label on this issue. You need a 'kind' label to start the triage process.
DetailsI am a bot created to help the crowdsecurity developers manage community feedback and contributions. You can check out my manifest file to understand my behavior and what I can do. If you want to use this for your project, you can check out the BirthdayResearch/oss-governance-bot repository. |
/area lapi |
Would be awesome to see this in upcoming release, as a hosting company we need more metadata to track bans done by appsec. Especially the http_host header, since we have thousands of domains that are protected by appsec 👍 |
+1. Great suggestion, would definitely use. This could also be used to customize the message that people see on their error page. |
Currently, the only way to influence the behaviour of a bouncer when applying a decision is to use the
type
attribute of the decision, but this is not very generic, and bouncers need to explicitly handles them.We could introduce the notion of metadata in decisions to allow for a more generic runtime control of bouncers.
For example, let's say we have a scenario called
rate-limiting
whose goal is to detect users abusing a specific endpoint, and we want to return a 429 status code for a short time, using the nginx bouncer.There's no easy way to achieve this at the moment:
ban
andcaptcha
remediationIt would be very useful to be able to set arbitrary metadata in a decision when it is created:
or with
cscli
:When the bouncer fetches the decisions, if there is metadata associated with a specific decision, it would appear in the stream:
Each bouncer would know about specific metadata (for example, all bouncers operating at the HTTP could be aware of the
status_code
attribute), and could change their configuration at runtime for a specific decision based on what they received.In this example, only
1.2.3.4
would receive a 429 return code, while all other decisions would use the default specified in the bouncer configuration.The text was updated successfully, but these errors were encountered: