-
Notifications
You must be signed in to change notification settings - Fork 200
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
feat(authentication): gRPC service definition for AuthenticationMethodTokenService #1102
Conversation
Codecov Report
@@ Coverage Diff @@
## authentication #1102 +/- ##
==================================================
- Coverage 80.80% 80.52% -0.28%
==================================================
Files 26 32 +6
Lines 1870 2193 +323
==================================================
+ Hits 1511 1766 +255
- Misses 279 342 +63
- Partials 80 85 +5
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
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.
looking good! just some minor typos. I think we just need to make the changes we talked about today with enabled
-> required
so that auth is always 'enabled' but not 'enforced' if off
I am exploring the approach of not using mocking, rather, using in-memory representations of dependencies.
Would like to hear your thoughts. I had a colleague previously who was passionately anti-mock.
That just testing against an in-memory implementation that was maintained to be functionality equivalent, gave a more representative test suite.
I am unsure, but I thought I could give it a go here.
I totally agree in re: to mocking. I usually don't mock at all in the storage
layer and below, and prefer to use either sqlite
or in-memory stores. As far as the server
layer, i've been more relaxed and use mocking as I can more easily test error conditions that way. But im open to whatever
Cheers for the review @markphelps I actually have the config changes lined up in here #1114 |
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.
lgtm! one question
🚀 🌕 |
…dTokenService (#1102) feat(auth/method/token): initial gRPC server implementation test(server/auth/method/token): assert token creation via API chore(server/auth): synchronize server stop and fatal on error fix(storage): use flipt/errors package chore(server/auth): validate invalid error adapts appropriately feat(authentication): wire up grpc service and gateway feat(server/auth): define unary server interceptor feat(storage/auth): implement list authentications feat(storage/auth): list with method predicate feat(auth): configure initial token bootstrap process chore(auth): correct documentation typos fix(proto): change create token http method PUT to POST
Supports #779
FIxes: FLI-35
Another one for the token-based auth series of changes.
This change includes the gRPC definitions for static token creation.
It implements the bridge between the creation token transport to the authentication storage.
Additionally, I did a little shuffling.
I moved the
auth
related storage up fromstorage/sql/auth
tostorage/auth
.Then beneath
storage/auth
I nested two storage typessql
andmemory
.I am exploring the approach of not using mocking, rather, using in-memory representations of dependencies.
Would like to hear your thoughts. I had a colleague previously who was passionately anti-mock.
That just testing against an in-memory implementation that was maintained to be functionality equivalent, gave a more representative test suite.
I am unsure, but I thought I could give it a go here.
Finally, this PR wires up
main
with the gRPC service and gateway implementations.This is guarded by the new
authentication.enabled
config flag.