-
-
Notifications
You must be signed in to change notification settings - Fork 27
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
fix: uncontrolled resource consumption #412
Comments
Hello @c3b5aw, thanks for your reporting. As well infrastructure autoscaling is not based on flow pressure and only on basic cpu / ram consumption. I have check on the monitoring dashboard https://dashboards.s42.app For collaborators and monitoring squad only (dashboard is not finished and stay private): https://dashboards.s42.app/d/KD4xvlJ4k/pod-dashboard?orgId=1&kiosk=tv&from=now-3h&to=now The objective of the autoscaling is to be based on custom data reported directly by the api pod metrics. Do you have a vision of that ? A desire to participe on the discussion ? Best regards |
Confirmed on our end, the issue is caused by an I will begin fixing it for the next release. |
…423) **Relative Issues:** Resolve #412 **Describe the pull request** This pull request addresses a potential security vulnerability by limiting the maximum content length accepted by the application. This measure helps to prevent possible Denial of Service (DoS) attacks that could be executed by sending excessively large payloads to the server. By enforcing a reasonable content length limit, we can maintain the application's stability and security while minimizing the risk of disruption from malicious actors. **Checklist** - [x] I have linked the relative issue to this pull request - [x] I have made the modifications or added tests related to my PR - [x] I have added/updated the documentation for my RP - [x] I put my PR in Ready for Review only when all the checklist is checked **Breaking changes ?** no **Additional context** A Directive Overloading occurs when a user can send a query with many consecutive directives and overload the parser of the app. Actually `gqlgen` don't allow us to add a fixed limit. I will work on gqlgen project to see if this can be implemented to respect the GraphQL 16 specifications about Directive Overloading.
Describe the bug
You can crash the API pod by overloading the graphql parser.
With a bit of threading you can take down the whole API:
To Reproduce
Expected behavior
No response
Relevant log output
No response
Version of software
idk
Environment
Live (https://s42.app)
Additional context
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: