expose a new client function to double-write siwe login info to the identity service
Details
Details
- Reviewers
ashoat • jon bartek - Commits
- rCOMM9df888d813d3: [keyserver] add loginUserWallet function
this gets tested in the next diff where we call loginUserWallet from user-responders.js
Depends on D6942
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
| keyserver/addons/rust-node-addon/src/identity_client/login_user.rs | ||
|---|---|---|
| 13–29 ↗ | (On Diff #23391) | we should probably refactor this into a call, like identity_client::open_channel |
| 37 ↗ | (On Diff #23391) | can we rename response to something more meaningful? like response_stream or something that doesn't sound like a singular discrete object? |
| 68 ↗ | (On Diff #23391) | handle_ makes it sounds like it's likely to fail, or doing a dispatch call. I would rather use something like get_ |
Comment Actions
Why is socialProof separate from siweMessage + siweSignature? Is it for the same reason that we pull signingPublicKey from sessionInitializationInfo (convenience)?
Comment Actions
yeah it's purely for convenience. i use siweMessage in the identity service to verify the siweSignature using the siwe-rs crate. the stringified socialProof goes directly into the DynamoDB table without any deserializaton
| keyserver/addons/rust-node-addon/src/identity_client/login_user.rs | ||
|---|---|---|
| 13–29 ↗ | (On Diff #23391) | refactored a little. the anonymous function in the with_interceptor function makes it hard to move the whole thing to a separate function because the result type is hard to type |