Proxy Wars: More QoL improvements for dApp connections #3613
Conversation
This continues to be managed in the window provider's mocking paths, but the cases where this is pulled from the metaMaskMock are expanded. When Taho is set as default, MetaMask-specific properties are pulled from the mock. This was already effectively happening for `isMetaMask`, but is now expanded to include _metamask and _state, which are also sometimes used to recognize MetaMask.
When a pending request is detected, new permission requests are immediately rejected, preventing cascading request popups for the user. Additionally, allow for a permanent permission denial to be recorded in the database. This isn't currently exposed in the UI, but follows from the implementation of disallowing parallel permission requests.
Two core changes here: - When proxying MetaMask calls, properties that resolve to functions are wrapped such that they maintain their `this` pointer at the underlying object rather than the proxy. - In development builds, all calls intercepted by the MetaMask wrapper are logged. This logging includes a timer log every 1s for longer- running calls, and applies both when Taho is set as default and when MetaMask is being called directly.
The `showExtensionPopup` helper previously returned the created window object, but offered no easy way to monitor for the closing of the window. We monitor for such a closing in more global ways for signature requests, mediated by the Main service; however, there are use cases where we need to manage internal state in the ProviderBridge service in a self-contained way. To allow this, a new `onClose` parameter is added to `showExtensionPopup`; it is a function that will be called when the popup window created by the function call is closed, no matter how it was closed.
This effectively rejects the permission request, and allows for future permission requests to come through normally. Previously, because this state was not cleared, the request was not treated as rejected from the dApp perspective (meaning the dApp would stay in a pending state that required a reload to recover from), and due to recent changes to disallow multiple parallel permission requests, future requests were immediately denied.
Previously, `#pendingPermissionRequests` had its value set in `requestPermission` but not cleared there, so it was hard to follow where that field was being managed. `requestPermission` now manages the full lifecycle of that value. Other places that were handling clean now only handle resolving the promise.
The actual implementation is a little more subtle: permissions are for an origin AND a network. If the permission being cleared is for the origin's current network, as tracked in the `InternalEthereumProvider`, then that current network is cleared so that future interactions can set it.
|
anything needed for this? testing? |
wallet_requestPermissions is defined by EIP-2255, but does not seem to have much use outside of an alternative to `eth_accounts` and a way to re-prompt the user for access to more/different accounts. For the time being, `wallet_requestPermissions` is implemented exactly like `eth_requestAccounts`, and `wallet_getPermissions` exactly like `eth_accounts`, except that the return value is structured somewhat differently. If and when Taho supports connecting multiple accounts to the same dApp simultaneously, we can extend this model with two things: - Always prompting the user to update their connected accounts when `wallet_requestPermissions` is invoked. - Returning more than one account in the `wallet_getPermissions` `restrictedReturnedAccounts` caveat.
Testing, yes! Hoping to ship this fella next week. |
…App permissions (#3616) Draft until I fill in some testing details. The actual implementation is a little more subtle: permissions are for an origin AND a network. If the permission being cleared is for the origin's current network, as tracked in the `InternalEthereumProvider`, then that current network is cleared so that future interactions can set it. Latest build: [extension-builds-3616](https://github.com/tahowallet/extension/suites/15762123848/artifacts/899755021) (as of Sat, 02 Sep 2023 20:14:11 GMT).
|
@Shadowfiend - some notes below from testing:
guild.xyz: So this one seems to behave as expected now. Support EIP 2255:
What I'm not sure about though is if that site really tests the "#3599 by clearing current network state when a disconnect on a matching account and network occurs. This can be tested by connecting to a dApp on a network, disconnecting, switching network, and attempting to connect again. Previously, the new connection would be on the original network, now it should be on the currently-selected network.": I connected to opensea.io on Polygon. I then disconnected in opensea.io and in the extension switched to Ethereum. I connected in opensea.io again but it connected on Polygon instead of Ethereum. I did essentially the same tests except on https://skurpytown.com/ in Brave. I connected on Optimism, disconnected, switched to Polygon in the extension, actually closed the tab for https://skurpytown.com/ and opened it in a new tab and connected again - it was still on Optimism: Screen.Recording.2023-10-30.at.11.17.18.AM.movHowever, I was finally able to get it to behave as expected when I went to background inspector > indexed db > internal-ethereum-provider > currentNetwork and I deleted skurpytown.com. It's still getting indexed that first time and then once I clear it from there, it doesn't happen again. I recreated it in this video with opensea.io. You can see it indexed when I start, that's from doing the test the first time. Then I delete the entry and run the test again and you can see the network correctly switch from Polygon to Optimism when I reconnect. The indexing isn't happening again after that first time, I can see that in the background page - it happens once then after I clear it, it seems to be good. opensea.mov |
Did you disconnect via the lightning bolt button in the wallet? That is the action that should clear the association since it is revoking the site permissions. Disconnecting in the dapp UI isn't expected to clear it, from what I understand. |
Yea, should have noted that. I tried disconnecting from within the extension and from within the dapp (just to try it all) - neither case gave me the results I expected until I cleared the entry from the currentNetwork index and then when I do that, it works like a charm. |
|
I might need to ride shotgun with you to understand this one better. Clearing the index is what should be happening in the first place (if, as beem notes, you disconnect from the lightning bolt in the extension), so having to do it manually first is puzzling. |
I have to leave soon but here's another video showing me using the lightning bolt to disconnect so hopefully that helps clarify to some degree and tomorrow I can definitely sit together to look at it. In this video, you can see that after I manually delete the indexed network, the dapp switches from Optimism to Polygon automatically. Polygon is what is was on when I connected the 2nd time and what it should have connected on. But instead, I had to manually delete that entry before it switched. lightningbolt.movAnd I think this will make it less confusing: it's still always doing the indexing for me. I had said it only does it once but now I can't recreate that scenario. Now, it's always indexing and the automatic switch when connecting on a different network won't happen unless I delete that entry. Should it be storing anything here at all after this change? Because these are all ones that have been stored since I started testing on this version today (ones that I haven't deliberately cleared yet). Or is it supposed to be storing them but then deleting/re-creating when we disconnect? I'm trying to understand if I should or should not see anything there with this change. |
|
Yeah on disconnect, it should be deleting them. I'll poke at it on my end as well. Odd that we're not seeing it… |
The property in the db was at network.chainID, looking at chainID was referencing an earlier version of the schema.
There was a problem hiding this comment.
Code looks ok, @andreachapman up to you if you prefer to merge it and do release testing or test it here again.
|
Looks like the latest build here doesn't include the fix from main for some reason… |
Shadowfiend
force-pushed
the
proxy-wars
branch
from
07a7b30
to
629807b
Compare
|
Rolling this in due to positive feedback from a couple of testers. We'll test the whole shebang together in a release PR. |
## What's Changed * v0.50.0 by @jagodarybacka in #3643 * Unsettled Networks: Clear an origin's current network when revoking dApp permissions by @Shadowfiend in #3616 * Sepo-Ledger: Patch @ledgerhq/hw-app-eth for Arbitrum Sepolia chain id handling by @Shadowfiend in #3650 * Proxy Wars: More QoL improvements for dApp connections by @Shadowfiend in #3613 **Full Changelog**: v0.50.0...v0.51.0 Latest build: [extension-builds-3652](https://github.com/tahowallet/extension/suites/17870144186/artifacts/1025746882) (as of Fri, 03 Nov 2023 02:06:50 GMT).
This PR:
thisassignment during proxy calls when impersonating MetaMask.wallet_requestPermissions) #3395 with a vestigialwallet_requestPermissions/wallet_getPermissionsimplementation.Additionally, it introduces logging for MetaMask-impersonated requests that includes timing information and parameter/return value/error value information:
This is similar to existing request/response logging in dApps, but it:
Latest build: extension-builds-3613 (as of Thu, 02 Nov 2023 22:01:18 GMT).