search

urbit / bridge

An application for interacting with Azimuth.
MIT License
96 stars 25 forks source link

keys: use sha256 token if unable to re-derive with keccak256 token #1000

Closed tomholford closed 2 years ago

tomholford commented 2 years ago

Context

When re-deriving a keyfile and access code within the Bridge dashboard, derive using both the default auth token (derived with keccak256) and an optional fallback token (derived with sha256, if necessary).

This resolves #549.

Testing

  1. git checkout t/549-auth-token-fallback
  2. npm run pilot-ropsten
  3. log in with mnemonic from DEVELOPMENT.md
  4. select ~winnet, navigate to Home > OS, and download Keyfile
tomholford commented 2 years ago

An update on this PR: while testing this change with the Invites feature, I ran into an issue: invites generated with a SHA token cannot be re-derived with a keccak token (and thus checked to see if they have been claimed).

Had an out of band conversation with @Fang- to brainstorm ideas. Will update once we've decided the path forward.

tomholford commented 2 years ago

cross-posting from conversation with Fang:

Did some more testing on this PR. It fixes the keys issue, but introduces a separate issue with the invites flow.

Using master, I logged in with my mnemonic, generated a few L2 invites with my star, then logged out. these invites were generated with the sha token. then, using the fix branch, I logged in with mnemonic again and navigated to the invites view. to render the list of invites, Bridge loads the outgoing points from the roller, then filters out the pending spawns and claimed points. to determine if a point is claimed, the invite point's inviteWallet is re-derived from the logged in auth token; then, the inviteWallet's ownership address is compared against the point's ownership address from the roller. if they match, it is considered unclaimed, and a URL is rendered for the invite. one naive approach is to try re-deriving the wallet with both types of tokens. but generating a wallet takes time, so this will significantly slow down the experience.

Will brainstorm other approaches with Fang and Product team

jamesacklin commented 2 years ago

to render the list of invites, Bridge loads the outgoing points from the roller, then filters out the pending spawns and claimed points.

Very open to a different, roller-side approach to this.

tomholford commented 2 years ago

to render the list of invites, Bridge loads the outgoing points from the roller, then filters out the pending spawns and claimed points.

Very open to a different, roller-side approach to this.

Good thinking, I will reach out to yosoyubik and get his thoughts.

tomholford commented 2 years ago

Following up with another update:

Spoke with @yosoyubik about this, he mentioned that ~tirrel is working on a custom gall agent that implements the invite flow (as an alternative to Bridge). Once it's finished, perhaps we can upstream part or all of its functionality into the roller. Then we could expose an endpoint that returns just the list of unclaimed invites. This would make the frontend experience in Bridge much smoother, and also avoid the "missing" invites issue described in this comment.

At this time, issue #549 is not mission critical - a simple workaround is for the user to login with whichever method they used to generate the keyfile / invites. As such, I propose that we wait for this new functionality to be available.

cc: @nerveharp

tomholford commented 2 years ago

After further conversation with @nerveharp, we have decided to close this in favor of #1012.