Page MenuHomePhabricator

[native] use identity wallet login in fullscreen-siwe-panel
ClosedPublic

Authored by varun on Feb 8 2024, 11:02 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Dec 24, 4:02 AM
Unknown Object (File)
Tue, Dec 24, 4:02 AM
Unknown Object (File)
Tue, Dec 24, 4:02 AM
Unknown Object (File)
Tue, Dec 24, 4:02 AM
Unknown Object (File)
Tue, Dec 24, 4:02 AM
Unknown Object (File)
Tue, Dec 10, 12:50 AM
Unknown Object (File)
Nov 14 2024, 10:15 PM
Unknown Object (File)
Nov 6 2024, 4:00 PM
Subscribers
None

Details

Summary

if usingCommServicesAccessToken, SIWE auth will now be done by the identity service

Test Plan

tested the following cases:

  • fresh eth wallet with enableNewRegistrationMode
    • was navigated to the new registration wizard
  • existing account with enableNewRegistrationMode
    • was logged in
  • fresh eth wallet with !enableNewRegistrationMode
    • was registered with identity service
  • existing account with !enableNewRegistrationMode
    • was logged in
  • invalid siwe signature
    • alert displayed

handling reserved users will be tackled in https://linear.app/comm/issue/ENG-4033/update-clients-to-try-new-registration-after-failed-login-due-to

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

varun requested review of this revision.Feb 8 2024, 11:17 PM
native/account/fullscreen-siwe-panel.react.js
79 ↗(On Diff #36897)

Shouldn't we also dispatch setDataLoadedActionType action? Or maybe we're waiting with it for Ashoat's keyserver to also auth?

native/account/siwe-hooks.js
104–110 ↗(On Diff #36897)

I guess we can simplify it, but that needs testing

native/account/fullscreen-siwe-panel.react.js
79 ↗(On Diff #36897)

my understanding was that we only want to set dataLoaded once we manage to connect to @ashoat 's keyserver

native/account/siwe-hooks.js
104–110 ↗(On Diff #36897)

i think we have to await it on line 109 too otherwise the error gets swallowed and we can't alert from the fullscreen panel

ashoat requested changes to this revision.EditedFeb 9 2024, 11:14 AM

enableNewRegistrationMode and onAccountDoesNotExist need to be handled here

native/account/fullscreen-siwe-panel.react.js
77–89 ↗(On Diff #36897)
  1. If enableNewRegistrationMode is set, then this call needs to fail if the account does not exist yet
  2. If the call fails because the account does not exist yet, then we need to call onAccountDoesNotExist
native/account/siwe-hooks.js
104–110 ↗(On Diff #36897)

@tomek's code is implicitly awaiting because dispatchActionPromise returns a Promise. He's suggesting it needs testing because that await might resolve at a slightly different time than the await siwePromise line

This revision now requires changes to proceed.Feb 9 2024, 11:14 AM
native/account/siwe-hooks.js
101 ↗(On Diff #36897)

This probably will need to handle doNotRegister

native/account/siwe-hooks.js
104–110 ↗(On Diff #36897)

@tomek's code is implicitly awaiting because dispatchActionPromise returns a Promise. He's suggesting it needs testing because that await might resolve at a slightly different time than the await siwePromise line

Exactly!

varun added inline comments.
native/account/siwe-hooks.js
104–110 ↗(On Diff #36897)

i tried @tomek 's approach initially and the alert in FullscreenSIWEPanel was not displayed on an error response from the identity service. on line 90 above we await siwePromise the same way, i presume for the same reason

varun marked an inline comment as done.

handle enableNewRegistrationMode and onAccountDoesNotExist

varun edited the test plan for this revision. (Show Details)

Should we "fall back" to the legacy workflow if the new one doesn't work?

Should we "fall back" to the legacy workflow if the new one doesn't work?

we have a new plan instead of a fallback mechanism including automated alerts, daily manual testing, and an opt-in mechanism for clients to inform us when there are issues

This revision is now accepted and ready to land.Feb 22 2024, 7:43 PM