[v5] Invalid projectId for InfuraProvider

[Mrtenz]

The included InfuraProvider class checks if the provided API key is a hexadecimal string here, to make sure an API key is technically valid, but throws an invalid projectId error in v5:

invalid projectId (argument="projectId", value="[my api key]", version=@TODO)

I had a quick look at the code and found this:

https:/ethers-io/ethers.js/blob/ethers-v5-beta/packages/providers/infura-provider.js#L41-L43 (I couldn't find the TS source)

The bytes_1.isHexString function uses a RegEx to check if a string is a hexadecimal string:

https:/ethers-io/ethers.js/blob/ethers-v5-beta/packages/bytes/index.js#L129-L131

The issue here is that it checks if the string starts with 0x though. Infura API keys don't start with 0x, and adding it would probably result in errors because the API key would be invalid (didn't test this).

I guess a temporary workaround for this would be to use the JsonRpcProvider and manually specify the Infura URL with API key.

[Mrtenz]

Found the actual source code... :)

https:/ethers-io/ethers.js/blob/ethers-v5-beta/packages/providers/src.ts/infura-provider.ts#L17-L19

https:/ethers-io/ethers.js/blob/ethers-v5-beta/packages/bytes/src.ts/index.ts#L179-L181

Unrelated, but is there a reason why the dist files are published to Git? It's common practice to not include those files.

[ricmoo]

Ah! Good catch. I will fix it right away.

They are included for two reason; first of all they are super handy. That way people don’t need to install the entire build-chain to get them... I use them all the time and am sad when a project does not include them, since building can sometimes be fairly involved, and often I just want ”try out” the library to see if will do what I want. :)

Secondly, it is part of the deterministic build. I haven’t migrated from v4 yet, but if you check out the “test-build” test in v4, it will fail the build if a pristine checkout of ethers does not result in building the exact same file. This prevents even me from manipulating the dist files (without other weird code that would look odd at best). Not that I plan to become evil or anything and try hiding exploits in the dist files, but it is more to protect against the type of attack that was issued against eslint. If my computer was infected with code designed to inject an exploit into the dist file, the build would fail, a diff would show why and where and the new version would not get published to npm or the CDN. Obviously a clever attacker could get around this, but raises the bar a little. :)

[ricmoo]

This should be fixed in the latest v5. Make sure you blow away your node_modules, npm/yarn lock files, etc. before doing an npm install. And let me know if you have any more problems.

Thanks again for beta testing the new release! :)