-
Notifications
You must be signed in to change notification settings - Fork 412
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
Rework Endpoint authentication #2947
Conversation
|
||
case object None extends AuthType { type ClientRequirement = Unit } | ||
case object Basic extends AuthType { type ClientRequirement = Header.Authorization.Basic } | ||
case object Bearer extends AuthType { type ClientRequirement = Header.Authorization.Bearer } |
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.
FYI, there could the some more use cases:
- Custom header like
X-API-Key
. The header name can vary. - Combination of multiple auth types: I have some endpoints that support both Bearer and
X-API-Key
. - I don't have that kind of use case, but there might be needs for cookie based authentication, when the endpoint need to support plain web browsers.
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 for the feedback. I want to get comments about the general design. But we can make auth type a FP DSL with fallback. And I want to add more options for sure. Maybe we can make it work that users can define custom auth types. We actually only need the ClientRequirement and a Codec fo the server. But this all depends on the authorization
header.
A more generic solution would then also need to define the header type and the client requirement/codec would need to use this header type. This would still work. The question is, if it is worth the effort.
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.
Sure, take you time. I just wanted to inform my use cases that may affect the design e.g. multiple auth types, not to force you to add all the missing stuff right now 😅
In general, I think replacing endpoint middleware with dedicated auth input is way more practical, because it was alway difficult to imagine a general endpoint middleware that takes into account server, client, and documentation with necessary type juggling that may affect all the type members.
bd4c27d
to
45b8fbc
Compare
@987Nabil This is the sort of approach I was envisioning. It looks directionally correct and a big cleanup. Do you need any assistance with anything in particular? |
@jdegoes I just wanted to know if I am walking the right path. I'll continue then and let you know when it is ready for review |
adc83b0
to
9c27ef9
Compare
a43921f
to
55b351f
Compare
Codecov ReportAttention: Patch coverage is
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #2947 +/- ##
==========================================
+ Coverage 64.78% 66.33% +1.54%
==========================================
Files 157 154 -3
Lines 9395 9687 +292
Branches 1743 1799 +56
==========================================
+ Hits 6087 6426 +339
+ Misses 3308 3261 -47 ☔ View full report in Codecov by Sentry. |
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.
Brilliant!
zio-http/shared/src/main/scala/zio/http/endpoint/Endpoint.scala
Outdated
Show resolved
Hide resolved
55b351f
to
6c57a94
Compare
@987Nabil Going to merge. However, with an endpoint that requires authentication, it should be mandatory to supply the authentication information to the typesafe Endpoint client. This is not currently implemented, but I think it's a big enough PR to merge anyway. |
@jdegoes This is still a draft, because I want some feedback, but have some tidy up work to do and add all auth options.
The idea behind the design is:
AuthType
Header.Authorization.XXX
. Which of these is required is defined inAuthType.ClientRequirement
For documentation purposes, all auth related information should be part of
AuthType
. We could add here also meta information like scopes.wdyt?
fixes #2888
/claim #2888