Page MenuHomePhabricator

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

Authored by ashoat on Apr 24 2024, 12:40 PM.
Tags
None
Referenced Files
F3504381: D11762.id39448.diff
Fri, Dec 20, 8:49 AM
F3501181: D11762.diff
Fri, Dec 20, 3:31 AM
Unknown Object (File)
Nov 9 2024, 6:48 AM
Unknown Object (File)
Nov 8 2024, 4:45 AM
Unknown Object (File)
Oct 12 2024, 2:40 PM
Unknown Object (File)
Oct 12 2024, 2:40 PM
Unknown Object (File)
Oct 12 2024, 2:40 PM
Unknown Object (File)
Oct 12 2024, 2:40 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
No Lint Coverage
Unit
No Test Coverage