-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Allow authentication via URI query parameter #642
Allow authentication via URI query parameter #642
Conversation
Introduce new annotation for resources that makes the authentication filter look at the URI query for a parameter containing the API key instead of a header. This enables clients that cannot supply headers to use authentication- locked resources. Signed-off-by: Kirill.Sybin <kirill.sybin@lex-com.net>
I asked in the issue whether to implement this as a generally available alternative to passing the API key via header without having to explicitly enable it, or as behavior that has to be activates, but got no reply. So I did it the latter way, that changes nothing about existing behavior until someone activates it for them. Let me know if this implementation is okay, then I'll add tests for it. If not, well I still look forward to the feedback :) |
alpine-server/src/main/java/alpine/server/auth/AuthenticationWithUriQuery.java
Outdated
Show resolved
Hide resolved
alpine-server/src/main/java/alpine/server/auth/ApiKeyAuthenticationService.java
Outdated
Show resolved
Hide resolved
Renaming as per reviewer suggestion to better reflect its purpose: stevespringett#642 (comment) Signed-off-by: Kirill.Sybin <kirill.sybin@lex-com.net>
Implement reviewer suggestion to replace either-or logic of looking at the URI query parameter instead of the header into a hierarchy, which keeps the header as the preferred location for the API key in every case and makes the query parameter the opt-in alternative that's enabled by the annotation. Review: stevespringett#642 (comment) Signed-off-by: Kirill.Sybin <kirill.sybin@lex-com.net>
Actually, I couldn't think of tests that are neither trivial nor not more involved than what I will be testing with tests of the downstream project using this PR's feature (i.e. DependencyTrack/dependency-track#4059). Test coverage here isn't that huge, so there wasn't much for me to go off of or take inspiration from either :/. If you see tests as necessary, I'll accept ideas pointing me in a concrete direction what to test :). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @SaberStrat!
Introduce new annotation for resources that makes the authentication filter look at the URI query for a parameter containing the API key instead of a header.
This enables clients that cannot supply headers to use authentication- locked resources.
Addressed Issue
#641