Closed danfinlay closed 3 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?
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.
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.
@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
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.
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
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.
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.
Closing per Gudahtt's comment above, this now works.
Reported in https://github.com/MetaMask/metamask-extension/issues/5950