SFA sporadically not exposing a provider

[shayg]

We have just recently migrated to single-factor-auth@6.5.0 (just saw that 7.0.0 was published yesterday).

We Implemented a very simple setup:

On Web3auth’s end we have an aggregate verifier, and we login using Auth0. Once logged in we then pass the id_token to the SDK like so:

const web3AuthProvider = !sessionId
  ? await web3Auth.connect({
      verifier: Web3AuthDeps.socialVerifierName,
      verifierId: session.user.email,
      idToken: idToken,
      subVerifierInfoArray: [
        {
          verifier: session.user.loginProvider,
          idToken,
        },
      ],
    })
  : web3Auth.provider

This setup works, all variables you see here are accounted for and correct.

However - I noticed from our logs that sometimes web3Auth.sessionId has a value, but web3Auth.provider is null. This is directly correlated to an API call I can see happening in the background. The call is made to https://broadcast-server.tor.us/store/get with a query param called key. When this call fails (image attached), the provider isn’t available. For example:

I logged in before I started writing this post. The provider was available and the API call was successful. I refreshed the page just now, the call fails and the provider is null.

This isn’t something we can rely on in production, please advise

Failed request:

Response when fails:

The API request as cURL, this is reproduced also when just running this in the terminal (I can see the response changes):

curl 'https://broadcast-server.tor.us/store/get?key=04afffb4962f29d7e68b0410ebdabea19649a598c298b845629dd302a96959caeae4bee6314661fd7a14e76047466758a473b9a3411a27ef7b2386b4e92761f4f1' \
  -H 'authority: broadcast-server.tor.us' \
  -H 'accept: */*' \
  -H 'accept-language: en-US,en;q=0.9' \
  -H 'origin: https://app.grappa.xyz' \
  -H 'referer: https://app.grappa.xyz/' \
  -H 'sec-ch-ua: "Chromium";v="116", "Not)A;Brand";v="24", "Google Chrome";v="116"' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'sec-ch-ua-platform: "macOS"' \
  -H 'sec-fetch-dest: empty' \
  -H 'sec-fetch-mode: cors' \
  -H 'sec-fetch-site: cross-site' \
  -H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36' \
  --compressed

[vjgee]

@shayg Thanks for your recent communication.

Your issue has been forwarded to our Dev team and we will get back with further updates.

[omryo]

any update??? it’s been more than a week.

[maharshi]

Hey @omryo @shayg, we have fixed few things with the provider with 7.0.1. Please update and let me know, if you still face this issue.

[omryo]

thanks, but why did we had to contact you in order to get an update? is 8 days a legitimate SLA (could have been much longer) ?

[maharshi]

We are sorry for the inconvenience but we are planning on informing priority teams via GitHub bot on SDK releases specific to their use case.
Several releases took place within a week hence requesting you to ignore this as a rare scenario.
Also, this issue was not noticed on the community as a widespread issue, hence did not gain much traction.
Please upgrade and let us know if you’re still facing this issue, we will be more than happy to help.

[shayg]

Then by all means, LOOK CLOSER.

We upgraded and deployed the new SDK: @web3auth/single-factor-auth@7.0.1 and @web3auth/ethereum-provider@7.0.2.

We are getting the same behavior:

1. The calls to store/get fails with 404
2. The SDK returns a provider
3. This code breaks on the second line (the provider returned by your SDK is missing a signer):

const provider = new ethers.providers.Web3Provider(web3AuthProvider)
const address = (await provider.getSigner().getAddress()).toLowerCase()

The same setup works for other accounts and the provider DOES have a signer (when store/get doesn’t return 404) - so as I see it: It’s the same issue, which are you are not providing us a solution for. Isn’t that what we pay for with “Enhanced Community Support + Technical Advisory Call”?

If you need help debugging your code and infrastructure, we’ll be happy to hop on a call

[maharshi]

@shayg We are here to support you. So please follow the community guidelines so as to prevent getting your post flagged.
Would you mind letting me know the ethers.js version you’re using?

[shayg]

We are running ethers version 5.7.2

[maharshi]

Hey @shayg,
You said auth0 and aggregate verifier, we have an example just for your use case. I’ll leave the link here. This works like a charm.

[shayg]

Does this example include persistent sessions? This doesn’t showcase something we can use in production as keep logging in isn’t something we are willing to tolerate.

Also, we mentioned in the original post the symptoms we are seeing (failing API calls to the default storage server). Can you please address this? The problem is this setup SOMETIMES works

[shayg]

Anything? It’s been a week (again)

[maharshi]

I would request you to try out the examples, the sessions are meant to be persistent until the time given in the sessionTime parameter hasn’t expired. Check out the SDK reference where sessionTime is mentioned. Try tweaking that and check if that works for you. If it doesn’t let’s arrange a call with your team in order to get this resolved.