floating / eth-provider Goto Github PK

I have seen your example here
NomicFoundation/hardhat#1159 (comment)

and I follow you instructions

    const frame = ethProvider('frame');
    const contractFactory = await ethers.getContractFactory("MyContract");
    const tx = await contractFactory.getDeployTransaction();

but get this:

 const tx = await this.signer.sendTransaction(unsignedTx);                              ^
TypeError: Cannot read properties of null (reading 'sendTransaction')

Also, can your example be adapter to deploy an upgradable contract?

const test = await upgrades.deployProxy(contractFactory);

Hi, @floating @mholtzman,I’d like to report a vulnerability introduced in your package eth-provider:

Issue Description

A vulnerability CVE-2021-32640 detected in package ws(<5.2.3,>=6.0.0 <6.2.2,>=7.0.0 <7.4.6) is directly referenced by [email protected]. We noticed that such a vulnerability has been removed since [email protected].

However, eth-provider's popular previous version [email protected] (4,847 downloads per week) is still transitively referenced by a large amount of latest versions of active and popular downstream projects (about 32 downstream projects, e.g., use-wallet 0.9.0, @binance-chain/bsc-use-wallet 0.8.1, @sekmet/next-auth 0.1.49, cryptowalletconnector 1.0.14, hubot-kredits 3.8.0, @aragon/[email protected], etc.).
As such, issue CVE-2021-32640 can be propagated into these downstream projects and expose security threats to them.

These projects cannot easily upgrade eth-provider from version 0.2.5 to (>=0.7.0). For instance, [email protected] is introduced into the above projects via the following package dependency paths:
(1)@aragon/[email protected] ➔ [email protected] ➔ @web3-react/[email protected] ➔ [email protected] ➔ [email protected]
......

The projects such as @web3-react/frame-connector, which introduced [email protected], are not maintained anymore. These unmaintained packages can neither upgrade eth-provider nor be easily migrated by the large amount of affected downstream projects.
On behalf the downstream users, could you help us remove the vulnerability from package [email protected]?

Suggested Solution

Since these inactive projects set a version constaint 0.2.* for eth-provider on the above vulnerable dependency paths, if eth-provider removes the vulnerability from 0.2.5 and releases a new patched version [email protected], such a vulnerability patch can be automatically propagated into the 32 affected downstream projects.

In [email protected], you can kindly try to perform the following upgrade:
ws 7.1.2 ➔ 7.4.6;
Note:
[email protected] has fixed the vulnerability (CVE-2021-32640)

Thank you for your help.

Best regards,
Paimon

User should be able to pass reconnection preferences in options

I have seen your example here
NomicFoundation/hardhat#1159 (comment)

and I follow you instructions

    const frame = ethProvider('frame');
    const contractFactory = await ethers.getContractFactory("MyContract");
    const tx = await contractFactory.getDeployTransaction();

but get this:

 const tx = await this.signer.sendTransaction(unsignedTx);                              ^
TypeError: Cannot read properties of null (reading 'sendTransaction')

Also, can your example be adapter to deploy an upgradable contract?

const test = await upgrades.deployProxy(contractFactory);

Hi, author. Thank you for this awesome library.

I have a problem connecting to infura goerli network using preset.
Error message => eth-provider | Invalid provider preset/location: "infuraGoerli"

const ethProvider = require('eth-provider');

const target = 'infuraGoerli'

this.provider = ethProvider(target, {
  infuraId: 'my infura id',
});

this.provider.send(
  'eth_chainId'
).then(console.log);

Kovan and other test networks are working ok.

It looks like a recent commit introduced a new console.log anytime process.env.NODE_ENV !== 'development'. Using the development environment will turn that log off but cause this to get logged instead:

A connection cycle started for provider with name: default
Successfully connected to: ws://127.0.0.1:8546

Adding some TypeScript definitions to the package would be really valuable!

It appears that the 'connect' event is being emitted before its provider is connected.

If I create a new Web3 instance as such:

const provider = require('eth-provider')
const Web3 = require('web3')
const web3Instance = new Web3(provider('ws://127.0.0.1:8546'))
web3Instance.currentProvider.connection.once('connect', () => {
  console.log(web3Instance)
})

The log output shows the provider as connected: false and status: loading

I believe the expected behavior should be that the 'connect' event is emitted iff the provider is connected and usable.

Let me know if I can help or if my understanding is incorrect. Thanks!

How to use this library in flutter web view to inject Wallet, Is there any way to download dist/eth-provider.min.js file to add in mobile wallet?

Hi @floating,

I'm opening this issue because between a few interested parties we had an open call today to discuss possible changes on EIP1193 and its release schedule. The call wasn't very representative, so nothing was decided, and we are scheduling another one.

As you are the author of this library and Frame, I think you may be interested in joining the next call, or the discord channel where this is being discussed. There are also some interesting discussions going on on ethereum magicians provider ring, and you may want to check them.

Best,
Patricio

I use the reactjs develop dapp, this provider can use in reactjs?

User should be able to pass custom origin in options

It seems to me that eth-provider fails to fallback to the next target.

I am trying to use eth-provider connected to frame and if frame is not available/running it should fallback to infura.

The call to connect to frame fails with an SyntaxError: Unexpected end of JSON input error and thus the provider does not try to do the call through the next target.

my code:

const Web3 = require('web3');
const provider = require('eth-provider');

web3 = new Web3(provider('frame', 'infuraRinkeby'));
web3.eth.getBlockNumber().then(console.log)

which will result in:

(node:24771) UnhandledPromiseRejectionWarning: #<Object>
(node:24771) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 2)

The error seems to happen in: https://github.com/floating/eth-provider/blob/master/connections/http.js#L103
A console.log in the catch block gives:

SyntaxError: Unexpected end of JSON input

Do you have an idea? If I understand the readme correct it should automatically fall back to infura in my code above, shouldn't it?

Line causing crashes.

Although EIP-1193 loosely defines events as being emitted through EventEmitter, there is no actual hard spec that says the window.ethereum object must be an EventEmitter implementation (nor which API version).

This has lead to some environments where the window.ethereum object doesn't implement an emit() API (e.g. Status), and thus crashes eth-provider.

Furthermore, it seems like this bit of code (monitor()) only serves to add a few additional events to the provider which are not included in EIP-1193 and are not used internally at all. I assume Frame uses these events?