InfuraProvider does not support Infura v3 endpoints

[jasonbukowski]

Infura is currently transitioning its users from their previous API to their new v3 API, and are warning that the old API will be taken offline.

https://blog.infura.io/introducing-the-infura-dashboard-8969b7ab94e7

The endpoints for the v3 API are different than the previous version (and those supported in the current InfuraProvider). They have also stated plans to update how authentication is handled in the future on their v3 platform.

For the time being, one can use the Infura v3 platform through the use of the JsonRpcProvider. Any plans to support Infura v3 in the short-term? I'm willing to contribute an update myself, I am just uncertain if it would be preferable to create an separate InfuraV3Provider, or to add a parameter to the existing InfuraProvider to indicate 'use v3'. Thoughts?

[ricmoo]

Thanks for the heads up!

Absolutely I intend to continue supporting INFURA, so I’ll look more into this soon.

Thanks! :)

[ricmoo]

I've reached out to INFURA. I've also updated my local version to support the v3. Remaining questions before I commit the changes:

• I currently detect legacy apiAccessToken vs projectId based on whether the string is a 16 byte hex string (32 nibbles); is this safe, going forward? Or should I test whether the string is 21 base58 characters, which was the old API Access token format
• Is it safe to hard-code a default Project ID in the library? I think this should be fine, but need to make sure.
• Is there a "blackhole" Project ID I can use, or a way to make my project a metric blackhole, so that I do not have access to the metrics gathered by people using the default Project ID; I do not want access to this data, and would prefer a semi-provable way to demonstrate I do not have this data.

[ricmoo]

It is January 23rd, so I'm committing the changes, and I'll keep bugging INFURA for more information on the above issues, but in the mean time the Project ID will be supported once the new version is posted later today.

[ricmoo]

This has been added to 4.0.22. An additional property projectId has been added. If the token passed in follows the Project ID format, it is populated, otherwise the legacy apiAccessToken is populated and the legacy URL is used to maintain backwards compatibility.

In v5 (still a private repo), the apiAccessToken has been removed and only the ProjectID is supported.

Thanks! :)

[Destiner]

Might worth writing about projectId in the docs.

[ricmoo]

Excellent point! I've added it to my TODO. :)

[naddison36]

Can I confirm that support for Infura v3 API is only in Ethers.js 4.x and not 3.x. Anyone wanting to continue to use Infura past 27 March with Ethers.js needs to upgrade to Ethers.js 4.x, correct?

[ricmoo]

That is correct. And in ethers v5, only INFURA v3 is supported.

I will be marking v2 deprecated in npm soon too, with a notice to upgrade to v4 or v5.

If there is enough demand, I could back-port INFURA v3 to ethers v3 too, but it is a bit of a headache, so only if people really need it, preferably. :)

[naddison36]

I've found a workaround. Just use the JsonRpcProvider and set the url to the Infura v3 API. eg https://kovan.infura.io/v3/<your project id>

[ricmoo]

Ah yes... Perfect work around for v3 users. I won't bother back-porting. :)