Page MenuHomePhabricator

[lib][native] Defer saving user credentials until successful auth
ClosedPublic

Authored by ashoat on Wed, Apr 24, 12:42 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Apr 30, 6:44 PM
Unknown Object (File)
Tue, Apr 30, 3:21 PM
Unknown Object (File)
Tue, Apr 30, 10:24 AM
Unknown Object (File)
Sun, Apr 28, 10:40 AM
Unknown Object (File)
Wed, Apr 24, 2:39 PM
Unknown Object (File)
Wed, Apr 24, 2:38 PM
Unknown Object (File)
Wed, Apr 24, 2:35 PM
Subscribers
None

Details

Summary

We're currently saving the user credentials after a successful auth with identity. This diff makes it so we wait until the whole auth concludes before we save the user credentials. This allows us to simplify some code, and is more consistent with how we're handling other side effects of auth: treating the auth as a single cohesive flow, and not considering it successful unless all parts succeed.

Depends on D11765

Test Plan

This whole stack was tested with the following steps:

  1. On native, attempting to log in with an ETH account that hasn’t been registered yet
  2. On native, attemping to register with an ETH account that has already been registered
  3. On native, log in with an ETH account that has already been registered
  4. On native, register with an ETH account that hasn’t already been registered
  5. On native, register with a password account
  6. On native, log in with a password account
  7. On web, attempting to log in with an ETH account that hasn’t been registered yet
  8. On web, log in with an ETH account that has already been registered
  9. On web, log in with a password account

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

lib/hooks/login-hooks.js
66 ↗(On Diff #39452)

It feels inconsistent that we set the currentUserInfo between identity and keyserver login, but wait to set user credentials. Why do we want to do that? The code in this diff doesn't seem to be simplified very much, but seems to introduce this inconsistency

lib/hooks/login-hooks.js
66 ↗(On Diff #39452)

We set currentUserInfo immediately after identity auth because on web, it's the only place where we can store the userID in order to allow it to be used for Comm services auth. I had initially explored deferring setting currentUserInfo until after keyserver auth, but cancelled that task when I realized this. See this comment for more details.

As for why we want to defer setting user credentials, this is described in the diff description:

is more consistent with how we're handling other side effects of auth: treating the auth as a single cohesive flow, and not considering it successful unless all parts succeed

Where currentUserInfo being set is an implementation detail not visible to the user, saving the credentials is something that is visible to the user. The user does not understand the distinction between identity auth and keyserver auth; in their perception, if keyserver auth fails then that just means auth failed. It feels weird to have the credentials saved sometimes when auth fails, but not always.

inka added inline comments.
lib/hooks/login-hooks.js
66 ↗(On Diff #39452)

Oh, I missed that this is visible to the user. I understand now, thank you

This revision is now accepted and ready to land.Fri, Apr 26, 6:04 AM