MetaMask / extension-provider

A module for allowing a WebExtension to access the web3 provider from an installed MetaMask instance
MIT License
67 stars 28 forks source link

Does not work with EIP 1102 #3

Closed danfinlay closed 3 years ago

danfinlay commented 5 years ago

Reported in https://github.com/MetaMask/metamask-extension/issues/5950

danfinlay commented 5 years ago

I’m working on fixing our extension-provider to work with 1102 (lets other extensions talk to MetaMask, we have a project that wants to build on this API).

I’m finding that the 1102 methods don’t use the Port API, but instead use the sendMessage method: https://developer.chrome.com/extensions/runtime#method-sendMessage

To receive this message internally as we do currently, we have used the onMessage API: https://developer.chrome.com/extensions/runtime#event-onMessage

To receive the messages from an externally-generated request however, we have to use the onMessageExternal api instead: https://developer.chrome.com/extensions/runtime#event-onMessage

This means that while we’ve relied on some pretty beautiful styling referencing the source page so far (including hostname and even a site icon), when receiving a request from another extension, we are limited to a sender object that looks like this:

{"id":"hcngifffnhjmkppmmoniamaekimoeepp","url":"chrome-extension://hcngifffnhjmkppmmoniamaekimoeepp/popup.html"}

I guess we could do a lookup on the relevant extension store to render the related image? In the meanwhile, we could just render a generic extension icon, and the extension’s ID?

Any other ideas? Should we be able to extract more from that source url?

ErikBjare commented 5 years ago

Just wanted to chime in, we're building the extension which needs this (https://github.com/SuperuserLabs/thankful).

Regarding the icon: I'm personally fine with a generic icon for now, if that leads to a quicker resolution.

danfinlay commented 5 years ago

Sorry for the slow development on this, thanks for reminding us this is still valuable to you. I think you may now be able to trigger the login request using the eth_requestAccounts RPC method.

Powersource commented 4 years ago

@danfinlay thanks for the tip. However this does not seem to work (with privacy mode on), no permission popup appears. More details in this PR https://github.com/SuperuserLabs/thankful/pull/215

deluca-mike commented 4 years ago

Any movement here? eth_requestAccounts is still not usable when called from another extension.

const pluginStream = new PortStream(metamaskPort);
const web3Provider = new MetamaskInpageProvider(pluginStream);

web3Provider.sendAsync({ method: 'eth_requestAccounts' }, console.log);
web3Provider.send({method: 'eth_requestAccounts'}, console.log);

Neither resulting in any error or callback, so there is currently no way to ask the user to approve another extension.

danfinlay commented 4 years ago

A little update here:

Getting this working was requiring a refactor of our transport layer, and we were already in the midst of a project that refactored this same layer, so this got bumped a bit in priority since we were going to get most of the work for free.

You can learn a bit about this new type of login system coming soon. When it lands, adding this feature should suddenly be very easy: https://ethereum-magicians.org/t/web3-login-permissions/3583/16

danfinlay commented 4 years ago

Slight update on the above: That permissions system is on our develop branch, and we're just a sprint or two (2-4 weeks) from getting that into production, at which point we should be able to do this very easily as noted above.

Gudahtt commented 4 years ago

The extension was updated in https://github.com/MetaMask/metamask-extension/pull/7218 to support connecting to an external extension, so this issue should no longer be blocked. Sending eth_requestAccounts should work just as it would for a normal dapp.

danfinlay commented 3 years ago

Closing per Gudahtt's comment above, this now works.