Page MenuHomePhabricator

[native] Don't send reserved ETH addresses to registration flow
ClosedPublic

Authored by ashoat on May 5 2024, 9:09 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Nov 24, 6:50 AM
Unknown Object (File)
Nov 18 2024, 4:42 PM
Unknown Object (File)
Nov 18 2024, 4:31 PM
Unknown Object (File)
Nov 18 2024, 2:35 PM
Unknown Object (File)
Nov 11 2024, 8:37 PM
Unknown Object (File)
Nov 11 2024, 11:53 AM
Unknown Object (File)
Nov 11 2024, 5:11 AM
Unknown Object (File)
Nov 11 2024, 2:24 AM
Subscribers

Details

Summary

This fixes an issue I identified in ENG-8044, which is that we send ETH accounts that have been reserved with the primary keyserver to the registration flow. These accounts should not need to go through the registration flow; rather, they should be able to transparently login via the reserved usernames workflow.

The code change was inspired by the equivalent logic in ConnectEthereum here.

Note that after this diff, the login will still fail. ENG-4033 tracks updating the logic here (and in ExistingEthereumAccount) to try to register the account via the reserved usernames workflow (rather than a simple login).

I considered factoring this logic out, since both ConnectEthereum and FullscreenSIWEPanel need to check this. But in ENG-4033 we'll probably need to refactor that check anyways, since we'll want to behave differently in the case of a reserved username versus a fully-registered account.

Would normally put @varun on this, but as he's out I figured @inka would be a good reviewer.

Test Plan

Try logging in as comm.eth on staging. Confirm that it simply fails now, instead of redirecting the user to the registration flow

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable