lock metadata write with postbox key #10
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Can we Lock the metadata write with
postboxKey
orOAuthKey
instead oftKey.privateKey
?Issue background
This PR is related to MPC Corekit concurrent sign ups issue, Web3Auth/mpc-core-kit#115 and Web3Auth/mpc-core-kit#131.
When a new user log into MPC-CoreKit with new email address, concurrently (This is edge case and not a very ideal case in the real scenario), each login session produce different keys (private keys, tss pubkeys) and shares. And also each session write different metadata to the metadata service, resulting in race condition. Normally, there's a
LOCK
to prevent race conditions before writing to metadata service. However, this metadata lock is tied with tKey instance private key (which is different in each login instance in case of concurrent sign ups), so theMETADATA LOCK
doesn't really prevent concurrent writing to metadata server and saving different metadata states for one account.Even though, user does not encounter any error during the concurrent sign ups, there is an issue when the same user (same email) log into another app (same email/login with different web3auth_client_id). For more info about the issue, please refer to this issue.
Expected behaviour
When user does the concurrent sign ups (login with new email), only the first instance should be allowed to set the metadata and all the later instances should throw an error (LOCK Error) since one instance has already acquired the
LOCK
for writing metadata to server.Proposed solution
Currently, the
METADATA LOCK
is tied totKey.privateKey
and it's not really preventing the write for concurrent sign ups since each signup creates new private key.So, instead of implementing lock with
tKey.privateKey
, is it possible to replace withtkeyServiceProvider.postboxKey
orOAuthKey
which we get from the logins/signups?Regardless of the concurrent logins/signups, all the instances will have the same
OAuthKey
, so we should be able to prevent the concurrent metadata writes for same account if we could useOAuthKey
to LOCK the metadata write. This will prevent multiple writes issues as well as solving thefactor not present
issue which we currently encounter inconcurrent logins