search

OriginProtocol / origin-js

We've moved to a monorepo: https://github.com/OriginProtocol/origin
MIT License
81 stars 33 forks source link

Identity Claims Not Found #591

Closed micahalcorn closed 5 years ago

micahalcorn commented 5 years ago

Several of us are able to reproduce an issue where phone, email, etc are supposedly published successfully, but they are gone when the profile page is refreshed. Upon further inspection, they appear to be recording, but @tyleryasaka suspects that the ATTESTATION_SIGNING_KEY may be wrong causing the attestations to be invalidated when retrieved. This is probably the top priority at the moment, but it may only be affecting the local environment.

franckc commented 5 years ago

Here is the check I did before deploying contracts to mainnet:

I used this script to validate that the address ISSUER_PROD matched the ATTESTATION_SIGNING_KEY defined in ENVKEY: var Web3 = require('web3') const web3 = new Web3() console.log(process.env.ATTESTATION_SIGNING_KEY) web3.eth.accounts.privateKeyToAccount(process.env.ATTESTATION_SIGNING_KEY)

tomlinton commented 5 years ago

@micahalcorn what kind of setup were you using when you say local environment?

micahalcorn commented 5 years ago

@tomlinton raw origin-dapp with BRIDGE_SERVER_DOMAIN=bridge.dev.originprotocol.com and local origin-js.

franckc commented 5 years ago

@micahalcorn @tyleryasaka I'm trying to understand the impact of this issue. Do we have any evidence this is happening in prod ?

micahalcorn commented 5 years ago

Haven't tried yet 😐 Has anyone published attestations, refreshed the page, and they're still intact? I heard vague indications to the contrary, but I'm not sure.

tomlinton commented 5 years ago

I can save/refresh them on staging without any problems. Haven't tried on production. That's a bit of an unusual setup you were running. I'm trying to think of why it would have not worked but I haven't come up with anything yet. :unamused:

franckc commented 5 years ago

I just tested on Mainnet. I saved my profile and it was still intact after I reloaded the page. Now there is a known bug (see DApp PR 639) where upon publishing, the DApp fails registering callbacks and therefore the profile page still shows status unpublished and the pending blockchain transaction dropdown stays stuck at 0% for the profile transaction.

franckc commented 5 years ago

As another data point, I just successfully published my email attestation on Mainnet. So I can't reproduce this issue on Mainnet so far...

franckc commented 5 years ago

Tyler fixed an attestation saving issue on mainnet: https://github.com/OriginProtocol/origin-js/pull/598

So now this issue is only about making sure we can use bridge.dev.originprotocol.com when developing locally.

Downgrading to p1

franckc commented 5 years ago

CC @tyleryasaka

Our bridge server setup is confusing:

  1. Both staging and prod bridge deployment use the prod ENVKEY. As a result attestations issued by both staging and prod bridge use the same ATTESTATION_SIGNING_KEY
  2. Though there is a separate ATTESTATION_SIGNING_KEY that is defined in ENVKEY for staging (but due to 1. it is not used)
  3. The contract migration script does not handle rinkeby. See code.

I can't really think of a good reason why this is setup this way. And I actually think it is not a good idea that both our staging and prod bridge servers use the same signing key.

How about the following:

@tyleryasaka any comment re this plan ? ^^^

tyleryasaka commented 5 years ago

@franckc just one thing to clarify:

We should make sure we do not add the rinkeby key to the mainnet issuer. Otherwise if anyone learns our rinkeby signing key they will be able to issue their own claims that appear to be valid in prod. I think this is what you meant, but just making sure.

Other than that looks great.

franckc commented 5 years ago

@tyleryasaka Yes, totally makes sense. I'll send a PR out and make sure to have you review it...

micahalcorn commented 5 years ago

Done via #764 ✅