Introduce fetchUserIDForEthereumAddress and use in siweAuthResponder to check if user exists and to complete login process (via call to successfulLogInQueries) if so.
Depends on D6059
Details
Details
Will be tested implicitly in future diffs. Will test thoroughly (lots of breakpoints to step through and ensure correctness) once account creation stuff is done.
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
| keyserver/src/responders/user-responders.js | ||
|---|---|---|
| 323 ↗ | (On Diff #20206) |
On point 2, it seems like the intention is to handle new user registration later, so accepting to unblock |
| 366 ↗ | (On Diff #20206) | We should probably still pass in a calendarQuery here... even though the client will always be resetting this to the default on log-in, we have no way to know the client's timezone here, so we might be off by a day. Can you create a task to track passing the calendarQuery up from the client? |
| 369 ↗ | (On Diff #20206) | Let's throw a ServerError for now if the account doesn't already exist, so we can keep the return type as not being nullable |
| keyserver/src/responders/user-responders.js | ||
|---|---|---|
| 323 ↗ | (On Diff #20206) |
Initially I'll always return LogInResponse (calling createSIWEAccount before processSuccessfulLogin if necessary) to get login/registration working end-to-end asap, and then will break the registration case down after. |
| 369 ↗ | (On Diff #20206) | Will update this diff |
| keyserver/src/responders/user-responders.js | ||
|---|---|---|
| 366 ↗ | (On Diff #20206) | |
Comment Actions
Having to revert this because of a stupid error, I should probably stop short-circuiting CI before landing...