Page MenuHomePhabricator

[SIWE] Differentiate content for social proof and backup message.
ClosedPublic

Authored by marcin on Apr 24 2024, 5:10 AM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Nov 15, 4:33 AM
Unknown Object (File)
Wed, Nov 13, 7:57 PM
Unknown Object (File)
Tue, Nov 12, 4:29 PM
Unknown Object (File)
Tue, Nov 12, 4:26 PM
Unknown Object (File)
Tue, Nov 12, 4:16 PM
Unknown Object (File)
Tue, Nov 12, 2:29 PM
Unknown Object (File)
Tue, Nov 12, 2:24 PM
Unknown Object (File)
Fri, Nov 1, 2:50 PM
Subscribers

Details

Summary

This differential introduces different SIWE message content for social proof and backup message.

Test Plan
  1. Ensure that siwe-utils.test.js pass during commit.
  2. I executed SIWE login flow and ensured that messages that appear in rainbow app match expected content.

Diff Detail

Repository
rCOMM Comm
Branch
marcin/eng-7930
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

Screen shot of rainbow app during social proof signature generation:

Screenshot_20240424-135140.png (2×1 px, 150 KB)

Screen shot of rainbow app during backup message signature generation:

Screenshot_20240424-135219.png (2×1 px, 151 KB)

ashoat added inline comments.
lib/utils/siwe-utils.js
83

Can we use a more specific type here?

96–99

If we can't use a more specific type easily, then maybe instead you can add an invariant here to make sure that the messageType is either one or the other option

This revision is now accepted and ready to land.Apr 24 2024, 6:29 PM
lib/utils/siwe-utils.js
83

Invariant can be avoided here and more specific type can be used. However this value is extracted from WebView headers in landing-handler. Therefore in order to avoid invariant here we will need to cast from string to SIWEMEssageType in landing-handler. This casting will have to use any. In my opinion it should be safe since in landing-handler we will use validator anyway before casting.

96–99

I think the invariant you are requesting is already added at line 89.