feat: Add authentication and personal user endpoint #29
Conversation
This contribution adds a lot of scaffolding for the database fake and testability of coderd. A new endpoint "/user" is added to return the currently authenticated user to the requester.
Codecov Report
@@ Coverage Diff @@
## main #29 +/- ##
==========================================
+ Coverage 69.30% 70.49% +1.18%
==========================================
Files 41 48 +7
Lines 1642 2159 +517
Branches 9 9
==========================================
+ Hits 1138 1522 +384
- Misses 402 496 +94
- Partials 102 141 +39
Continue to review full report at Codecov.
|
database/query.sql
Outdated
| -- name: GetUserByID :one | ||
| SELECT * FROM users WHERE id = $1 LIMIT 1; |
There was a problem hiding this comment.
Is this generated code? If so - we should add it to the .gitattributes file
There was a problem hiding this comment.
Nope! I'll add a docstring for how this works.
| // Tracks if the API key has properties updated! | ||
| changed := false | ||
|
|
||
| if key.LoginType == database.LoginTypeOIDC { |
There was a problem hiding this comment.
For our 'black triangle' scenario - are you thinking of supporting Built-In and OIDC? Or just OIDC login?
There was a problem hiding this comment.
This was just to bring parity to this code from our implementation in v1.
This does support OIDC, but doesn't require it at all. I imagine we'll use basic auth to start, but this makes OIDC easy to add.
| // Makes sure the context properly adds the User! | ||
| _ = httpmw.User(r) |
There was a problem hiding this comment.
Maybe worth validating that the return User id matches what we passed in? It's a simple invariant to check that may catch a regression later
There was a problem hiding this comment.
Overall looks good to me, just some minor nits. Thanks for implementing this, @kylecarbs !
| ) | ||
|
|
||
| // AuthCookie represents the name of the cookie the API key is stored in. | ||
| const AuthCookie = "session_token" |
There was a problem hiding this comment.
Will we be able to reuse this from v1? In other words - will session tokens from v1 be usable for logging in via v2?
There was a problem hiding this comment.
Yup, they will be! The API key validation is secure in v1, so we reuse a lot of similar logic in the v2 handler.
| Message: "👋", | ||
| }) | ||
| }) | ||
| r.Post("/user", users.createInitialUser) |
There was a problem hiding this comment.
Is it expected that the front-end will have to call this? Or we'll just run curl and POST to it in our ./develop.sh, to ensure that it's created?
There was a problem hiding this comment.
The front-end will call this!
v2 will have no concept of a "setup mode".
Co-authored-by: Bryan <bryan@coder.com>
This just implements a basic sign-in flow, using the new endpoints in #29 :  This brings over several dependencies that are necessary: - `formik` - `yep` Ports over some v1 code to bootstrap it: - `FormTextField` - `PasswordField` - `CoderIcon` And implements basic sign-in: Fixes #37 Fixes #43 This does not implement it navbar integration (importantly - there is no way to sign out yet, unless you manually delete your `session_token`). I'll do that in the next PR - figured this was big enough to get reviewed.
This contribution adds a lot of scaffolding for the database fake
and testability of coderd.
A new endpoint "/user" is added to return the currently authenticated
user to the requester.
Todo:
Create generated APIs for TypeScript and Go.