What problem are you trying to solve?
According to this EIP doc: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1102.md. The provider.enable() method of requesting access for dapps is to be dprecated in favor of the eth_requestAccounts do you guys have any guidance / plans around when this RPC will be supported? I was playing around and got the popup to appear but was not getting any available addresses back. Thanks!
Describe the solution you'd like
Guidance around eth_requestAccounts RPC call
Additional context
N/a
Found this in the code: https://github.com/MetaMask/metamask-extension/blob/c3176248544e3e0019389b1f177cac68087bfe8f/app/scripts/inpage.js#L156
That appears to be a function of some sort that redirects anything for 'eth_requestAccounts' to enable().
But .enable() appears to return a Promise per https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1102.md#providerenable-deprecated.
By contrast, the send() method of a Provider either does things synchronously/returns the result (if no callback is provided), or asynchronously/returns void (if a callback is provided) per https://github.com/MetaMask/metamask-inpage-provider/blob/e65640fd4b34537b548b7147abf2c3040df0d437/index.js#L71.
The sendAsync() method of a Provider does things asynchronously via callbacks per https://github.com/MetaMask/metamask-inpage-provider/blob/e65640fd4b34537b548b7147abf2c3040df0d437/index.js#L83
Thus, I am not sure how to use 'eth_requestAccounts' on MetaMask either. I tried it using both send({method: 'eth_requestAccounts'}, callback) and sendAsync({method: 'eth_requestAccounts'}, callback) but neither callback would ever execute, even after I clicked on the "Accept" button in the permissions request window that popped up. And restarted the browser. And switched back and forth between Ethereum networks.
Hi @BMillman19 and @uhhhh2, thanks for reaching out and for taking the time to read EIP-1102 and MetaMask source code.
First, some context around eth_requestAccounts may be useful. There's a related proposal to 1102 that standardizes a new Ethereum provider API, EIP-1193. This new provider API has some key differences from the existing provider API, one of which is replacing ethereum.enable() with a new RPC call, ethereum.send('eth_requestAccounts'). We're currently working with dapp browsers including Mist, Status, imToken, Opera, and Coinbase Wallet to determine when to begin to roll out this new API, but this most likely won't be until the second quarter of 2019. This final API change (which will involve more than just replacing enable calls, as ethereum#sendAsync goes away and ethereum#send has a new signature), is the final move towards a truly standard API that all dapp browsers will collectively implement, something the Ethereum community has been lacking since its inception. We plan to be very vocal with the community about this change long before it happens.
As for the eth_requestAccounts method that's currently in MetaMask, it can be called using ethereum.send({ method: 'eth_requestAccounts' }) and will return an identical value that ethereum.enable() would return: a Promise resolving to a list of accounts. This new RPC method was only included for bleeding-edge testing purposes and shouldn't be used for any production application.
For now, until you begin to see coordinated messaging from all major dapp browsers stating otherwise, ethereum.enable() is still the currently-implemented and proper way to request user accounts.
Hi @bitpshr , as of 03/2019, what is the current status and recommendation?
I found this issue while investigating a strange behavior, not sure if it is a bug. I'm trying to use the ethereum.send method, and found out that using await window.ethereum.send("eth_requestAccounts") works perfectly in the latest Google Chrome + Metamask 6.2.1, but fails in Firefox 65 + Metamask 6.1.0 (the latest Metamask at this moment) with the message:
Error: "The MetaMask Web3 object does not support synchronous methods like undefined without a callback parameter. See https://github.com/MetaMask/faq/blob/master/DEVELOPERS.md#dizzy-all-async---think-of-metamask-as-a-light-client for details."
Interesting that passing the string as an object like you recommended await window.ethereum.send({ method: "eth_requestAccounts" }) works in both browsers.
Anyway, should I go back to using the ethereum.enable() call or is it already stable enough to start using eth_requestAccounts?
Most helpful comment
Hi @BMillman19 and @uhhhh2, thanks for reaching out and for taking the time to read EIP-1102 and MetaMask source code.
First, some context around
eth_requestAccountsmay be useful. There's a related proposal to 1102 that standardizes a new Ethereum provider API, EIP-1193. This new provider API has some key differences from the existing provider API, one of which is replacingethereum.enable()with a new RPC call,ethereum.send('eth_requestAccounts'). We're currently working with dapp browsers including Mist, Status, imToken, Opera, and Coinbase Wallet to determine when to begin to roll out this new API, but this most likely won't be until the second quarter of 2019. This final API change (which will involve more than just replacingenablecalls, asethereum#sendAsyncgoes away andethereum#sendhas a new signature), is the final move towards a truly standard API that all dapp browsers will collectively implement, something the Ethereum community has been lacking since its inception. We plan to be very vocal with the community about this change long before it happens.As for the
eth_requestAccountsmethod that's currently in MetaMask, it can be called usingethereum.send({ method: 'eth_requestAccounts' })and will return an identical value thatethereum.enable()would return: aPromiseresolving to a list of accounts. This new RPC method was only included for bleeding-edge testing purposes and shouldn't be used for any production application.For now, until you begin to see coordinated messaging from all major dapp browsers stating otherwise,
ethereum.enable()is still the currently-implemented and proper way to request user accounts.