Page MenuHomePhabricator

[native] Upload secondary device keys when added to list
ClosedPublic

Authored by bartek on Mar 11 2024, 6:18 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Nov 10, 2:03 PM
Unknown Object (File)
Oct 27 2024, 8:20 AM
Unknown Object (File)
Oct 22 2024, 3:04 PM
Unknown Object (File)
Oct 22 2024, 3:04 PM
Unknown Object (File)
Oct 22 2024, 3:04 PM
Unknown Object (File)
Oct 22 2024, 3:04 PM
Unknown Object (File)
Oct 22 2024, 3:04 PM
Unknown Object (File)
Oct 22 2024, 3:04 PM
Subscribers

Details

Summary

After receiving information from primary device about successful device list update, secondary device should perform device keys upload. Then it should be able to start normal authenticated Tunnelbroker session.

Depends on D11294

Test Plan

Repeated test plan from D11294, and also made sure the secondary device keys have been uploaded. Monitored the isAuthorized Tunnelbroker prop - after successful RPC call, it switched to true.

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

bartek held this revision as a draft.
bartek edited the test plan for this revision. (Show Details)
bartek published this revision for review.Mar 12 2024, 2:19 AM
kamil added inline comments.
native/qr-code/qr-code-screen.react.js
40

deviceKeys we have this name in multiple places in codebase and different meanings which makes me a bit confusing - would be good to use something more specific but not sure what is the best option

57

I think you should use peerToPeerMessageValidator here

101

I think you can just return undefined?

This revision is now accepted and ready to land.Mar 13 2024, 5:52 AM
native/qr-code/qr-code-screen.react.js
77–79 ↗(On Diff #38125)

Nit: I think this can be simplified

native/qr-code/qr-code-screen.react.js
77–79 ↗(On Diff #38125)

Tried that, L83 fails destructuring