Skip to content
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

Custom responses based on content type and tags #144

Open
sporkmonger opened this issue Sep 12, 2023 · 0 comments
Open

Custom responses based on content type and tags #144

sporkmonger opened this issue Sep 12, 2023 · 0 comments
Labels
kind/enhancement A new piece of functionality, whether a feature implementation or an improvement to an existing one.
Milestone

Comments

@sporkmonger
Copy link
Contributor

In order to better support API security use-cases and provide better user feedback in case of a false positive, Bulwark should offer a mechanism of emitting a custom response instead of a hard-coded "Access Denied".

Responses should be loaded from a file path relative to the configuration file. The configuration should specify the status code and content type to deliver with the response. Additionally, the content type should be matched based on the order given in the Accept header in the request, otherwise the fallback order should be the order in which custom responses are defined.

Additionally, responses should be determined by tags, matching from most specific match to least specific. Content-Type should take precedence over tags to avoid delivering a response to a client that it cannot process. Generically there should be a custom response with no tags at all that can act as a catch-all.

Bulwark would still continue to supply it's own top-level generic response when no custom response matches. Bulwark should additionally add support for generic built-in responses for JSON endpoints, not just a text/plain "Access Denied" response.

@sporkmonger sporkmonger added the kind/enhancement A new piece of functionality, whether a feature implementation or an improvement to an existing one. label Sep 12, 2023
@sporkmonger sporkmonger added this to the Release 0.5.0 milestone Sep 12, 2023
@sporkmonger sporkmonger removed this from the Release 0.5.0 milestone Feb 16, 2024
@sporkmonger sporkmonger added this to the Release 0.7.0 milestone Apr 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement A new piece of functionality, whether a feature implementation or an improvement to an existing one.
Projects
None yet
Development

No branches or pull requests

1 participant