Fix bad error handling in api key auth #3935
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
blakerouse
added
the
Team:Elastic-Agent-Control-Plane
|
This pull request does not have a backport label. Could you fix it @blakerouse? 🙏
|
|
|
mergify
bot
added
the
backport-8.x
|
go-lint is very wrong here... idk |
blakerouse
requested review from
michel-laterman
and removed request for
andrzej-stencel
|
michel-laterman
approved these changes
Sep 20, 2024
mergify bot
pushed a commit
that referenced
this pull request
Sep 20, 2024
* Fix bad error handling in api key auth. * Don't return so much information. * bug-fix * Remove un-need changes. (cherry picked from commit 28e96bf)
4 tasks
blakerouse
added a commit
that referenced
this pull request
Sep 20, 2024
* Fix bad error handling in api key auth. * Don't return so much information. * bug-fix * Remove un-need changes. (cherry picked from commit 28e96bf) Co-authored-by: Blake Rouse <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What is the problem this PR solves?
Currently any error returned back to Fleet Server from elasticsearch that is not 401 or 429 is returned as a 401 error. This tells the calling client that the API key is invalidate. That is only true when the error is 401, otherwise the error means something different.
How does this PR solve the problem?
This solves the issue by returning the actual error back elasticsearch to the calling client. This means that a 500 error from elasticsearch will not result in a 401 back to the client, instead it will be a 500 error.
This uses the standard
es.ParseErrorlogic to determine the error and return something readable to the calling client.How to test this PR locally
Design Checklist
[ ] I have or intend to scale test my changes, ensuring it will work reliably with 100K+ agents connected.(no effect on scale)[ ] I have included fail safe mechanisms to limit the load on fleet-server: rate limiting, circuit breakers, caching, load shedding, etc.(no effect)Checklist
[ ] I have made corresponding changes to the documentation[ ] I have made corresponding change to the default configuration files./changelog/fragmentsusing the changelog toolRelated issues