Page MenuHomePhabricator

[lib] Don't try authing to authoritative keyserver from KeyserverConnectionHandler
ClosedPublic

Authored by ashoat on Wed, Apr 24, 12:40 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, May 1, 11:06 PM
Unknown Object (File)
Wed, May 1, 8:46 PM
Unknown Object (File)
Tue, Apr 30, 7:21 PM
Unknown Object (File)
Tue, Apr 30, 4:37 PM
Unknown Object (File)
Mon, Apr 29, 9:12 PM
Unknown Object (File)
Sun, Apr 28, 6:21 PM
Unknown Object (File)
Wed, Apr 24, 2:39 PM
Unknown Object (File)
Wed, Apr 24, 2:38 PM
Subscribers
None

Details

Summary

Now that registration and login components will be directly responsible for authing with the authoritative keyserver, we no longer want KeyserverConnectionHandler to handle it.

This addresses ENG-7675.

We additionally add a safeguard to avoid authing with any keyserver until currentUserInfo is set. This should be set around the same time that deviceToken is, but it appears to occur slightly later because SET_ACCESS_TOKEN is dispatched by AccessTokenHandler before the currentUserInfo is updated by the identity auth actions.

Note that KeyserverConnectionHandler will continue to own keyserver session recovery for the authoritative keyserver.

Depends on D11761

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