Can't login

[eusthace811]

Describe the bug For some reason, login using uport connect stopped working. I am not getting any notification after read QR using the mobile app so it's impossible for me to access my app.

It was working until yesterday.

I am using uport-connect 1.1.1.

Smartphone:

• Device: iPhone 7 Plus
• OS: iOS 12.4
• Version: 480 production

Additional context

async login(): Promise<any> {
    connect.requestDisclosure({ requested: ['name', 'email', 'country'], notifications: true });
    const result = await connect.onResponse('disclosureReq').catch( (error: any) => {
    this.did = result.payload.did;
    this.loadCredentials();
    return this.did;
  }

[mirceanis]

Thank you for reporting. It is a known issue and we're working on it. The fix in the mobile app is rolling out as I write this, please update when it becomes available.

[mirceanis]

It looks like there need to be changes here too, not only in the mobile app: https://github.com/uport-project/uport-connect/blob/6f0185d5788047b2ba9a2d98c2a8a2433d4e29d8/src/Connect.js#L215

verifyJWT will expect a Resolver

[eusthace811]

Ok, let me know and I will update lib and mobile app. Thanks for you help!

[simonas-notcat]

@mirceanis here is a solution that does not involve any changes to uport-connect

import { Connect } from 'uport-connect'

const uportConnect = new Connect('App', {
  // ...
  ethrConfig: {
    rpcUrl: 'https://mainnet.infura.io/v3/<YOUR INFURA PROJECT_ID>',
  }
})

[mirceanis]

@simonas-notcat Right! Thanks for coming up with this. It is usable as a temporary workaround.

However, this works for the wrong reasons, and will break under some situations. It overrides the global resolver registry with a configured ethr-did-resolver through the internal Credentials instance.

To anyone that is using this workaround, this only works with the following constellation of libraries:

• "did-jwt": "^0.x",
• "ethr-did-resolver": "^0.x"
• "uport-credentials": "^1.2.1" And, if you register ethr-did-resolver externally or create new instances of Credentials you need to pass in the same ethrConfig

[eusthace811]

Looks like its working after the last update, right?

[mirceanis]

The broken URL that was causing the issue has been temporarily reinstated. A more permanent solution involves configuring the resolver used during verification. The mobile app has also been patched with a configured resolver but the rest of the libraries will need this as well.

The next version of this lib will expect a resolver during initialization. Stay tuned for the next release with configuration instructions. Until then, you can use the workaround from above to guard your app against the URL getting disabled again.