We are working on migrating the extension to a unified network
controller, but before we do so we want to extract some of the existing
pieces, specifically `createInfuraClient` and `createJsonRpcClient`,
which provide the majority of the behavior exhibited within the provider
API that the existing NetworkController exposes. This necessitates that
we understand and test that behavior as a whole.
With that in mind, this commit starts with the Infura-specific network
client and adds some initial functional tests for `createInfuraClient`,
specifically covering three pieces of middleware provided by
`eth-json-rpc-middleware`: `createNetworkAndChainIdMiddleware`,
`createBlockCacheMiddleware`, and `createBlockRefMiddleware`.
These tests exercise logic that originate from multiple different places
and combine in sometimes surprising ways, and as a result, understanding
the nature of the tests can be tricky. I've tried to explain the logic
(both of the implementation and the tests) via comments. Additionally,
debugging why a certain test is failing is not the most fun thing in the
world, so to aid with this, I've added some logging to the underlying
packages used when a request passes through the middleware stack.
Because some middleware change the request being made, or make new
requests altogether, this greatly helps to peel back the curtain, as
failures from Nock do not supply much meaningful information on their
own. This logging is disabled by default, but can be activated by
setting `DEBUG=metamask:*,eth-query DEBUG_COLORS=1` alongside the `jest`
command.
We use this logging by bumping `eth-block-tracker`, and
`eth-json-rpc-middleware`.
* Update `eth-json-rpc-infura`
The package `eth-json-rpc-infura@5` has been updated to
`@metamask/eth-json-rpc-infura@7`. This update includes TypeScript
support, and it drops support for older node.js versions. The exports
have also been changed from default to named exports.
See here for a full list of changes: https://github.com/MetaMask/eth-json-rpc-infura/blob/main/CHANGELOG.md#700
* Fix LavaMoat policy issue
The `web3` package used by `@metamask/controllers` unintentionally
overwrites the `XMLHttpRequest` global, which breaks things. This was
fixed by revoking `web3`'s write access to that global using a policy
override.
Previously this policy override was applied to `web3`, but for some
unknown reason, this update caused that override to no longer apply.
* Version v10.18.4
* Fix default currency symbol for `wallet_addEthereumChain` + improve warnings for data that doesn't match our validation expectations (#15201)
* set more appropriate default for ticker symbol when wallet_addEthereumChain is called
* throw error to dapp when site suggests network with same chainId but different ticker symbol from already added network, instead of showing error and disabled notification to user
* Fix Provider Tracking Metrics (#15082)
* fix filetype audit (#15334)
* Remove decentralized 4byte function signature registry since it contains incorrect signatures and we can't algorithmically check for best option when 4byte.directory is down (#15300)
* remove decentralized 4byte function signature registry since it is griefed and we can't algorithmically check for best option when 4byte is down
* add migration
* remove nock of on chain registry call in getMethodDataAsync test
* remove audit exclusion (#15346)
* Updates `eth-lattice-keyring` to v0.10.0 (#15261)
This is mainly associated with an update in GridPlus SDK and enables
better strategies for fetching calldata decoder data.
`eth-lattice-keyring` changes:
GridPlus/eth-lattice-keyring@v0.7.3...v0.10.0
`gridplus-sdk` changes (which includes a codebase rewrite):
GridPlus/gridplus-sdk@v1.2.3...v2.2.2
* Fix 'block link explorer on custom networks' (#13870)
* Created a logic for the 'Add a block explorer URL'
Removed unused message
Message logic rollback
Modified history push operation
WIP: Pushing before rebasing
Applied requested changes
Removed unintenionally added code
* Lint fix
* Metrics fixed
* Stop injecting provider on docs.google.com (#15459)
* Fix setting of gasPrice when on non-eip 1559 networks (#15628)
* Fix setting of gasPrice when on non-eip 1559 networks
* Fix unit tests
* Fix logic
* Update ui/ducks/send/send.test.js
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
* [GridPlus] Bumps `eth-lattice-keyring` to v0.11.0 (#15490)
* [GridPlus] Bumps `gridplus-sdk` to v2.2.4 (#15561)
* remove exclusions for mismatched object jsdoc type casing (#15351)
* Improve `tokenId` parsing and clean up `useAssetDetails` hook (#15304)
* Fix state creation in setupSentryGetStateGlobal (#15635)
* filter breadcrumbs for improved clarity while debugging sentry errors (#15639)
* Update v10.18.4 changelog (#15645)
* Auto generated changelog
* Update 10.18.4 changelog
* Run lavamoat:auto
* Call metrics event for wallet type selection at the right time (#15591)
* Fix Sentry in LavaMoat contexts (#15672)
Our Sentry setup relies upon application state, but it wasn't able to
access it in LavaMoat builds because it's running in a separate
Compartment.
A patch has been introduced to the LavaMoat runtime to allow the root
Compartment to mutate the `rootGlobals` object, which is accessible
from outside the compartment as well. This lets us expose application
state to our Sentry integration.
* Fix Sentry deduplication of events that were never sent (#15677)
The Sentry `Dedupe` integration has been filtering out our events, even
when they were never sent due to our `beforeSend` handler. It was
wrongly identifying them as duplicates because it has no knowledge of
`beforeSend` or whether they were actually sent or not.
To resolve this, the filtering we were doing in `beforeSend` has been
moved to a Sentry integration. This integration is installed ahead of
the `Dedupe` integration, so `Dedupe` should never find out about any
events that we filter out, and thus will never consider them as sent
when they were not.
* Replace `lavamoat-runtime.js` patch (#15682)
A patch made in #15672 was found to be unnecessary. Instead of setting
a `rootGlobals` object upon construction of the root compartment, we
are now creating a `sentryHooks` object in the initial top-level
compartment. I hadn't realized at the time that the root compartment
would inherit all properties of the initial compartment `globalThis`.
This accomplishes the same goals as #15672 except without needing a
patch.
* Update v10.18.4 changelog
* Fix lint issues
* Update yarn.lock
* Update `depcheck` to latest version (#15690)
`depcheck` has been updated to the latest version. This version pins
`@babel/parser` to v7.16.4 because of unresolved bugs in v7.16.5 that
result in `depcheck` failing to parse TypeScript files correctly.
We had a Yarn resolution in place to ensure `@babel/parser@7.16.4` was
being used already. That resolution is no longer needed so it has been
removed. This should resove the issue the dev team has been seeing
lately where `yarn` and `yarn-deduplicate` disagree about the state the
lockfile should be in.
* Update yarn.lock
* Update LavaMoat policy
* deduplicate
* Update LavaMoat build policy
Co-authored-by: MetaMask Bot <metamaskbot@users.noreply.github.com>
Co-authored-by: Alex Donesky <adonesky@gmail.com>
Co-authored-by: Brad Decker <bhdecker84@gmail.com>
Co-authored-by: Alex Miller <asmiller1989@gmail.com>
Co-authored-by: Filip Sekulic <filip.sekulic@consensys.net>
Co-authored-by: Erik Marks <25517051+rekmarks@users.noreply.github.com>
Co-authored-by: Dan J Miller <danjm.com@gmail.com>
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
Co-authored-by: seaona <54408225+seaona@users.noreply.github.com>
Co-authored-by: seaona <mariona@gmx.es>
Co-authored-by: PeterYinusa <peter.yinusa@consensys.net>
The Sentry `Dedupe` integration has been filtering out our events, even
when they were never sent due to our `beforeSend` handler. It was
wrongly identifying them as duplicates because it has no knowledge of
`beforeSend` or whether they were actually sent or not.
To resolve this, the filtering we were doing in `beforeSend` has been
moved to a Sentry integration. This integration is installed ahead of
the `Dedupe` integration, so `Dedupe` should never find out about any
events that we filter out, and thus will never consider them as sent
when they were not.
* addding the legacy tokenlist, tuning token detection OFF by default, adding new message while importing tokens
updating the controller version and calling detectNewToken on network change
fixing rebase error
Run yarn lavamoat:auto for updating policies
updating lavamoat
Deleted node modules and run again lavamoat auto
fixing rebase issues
updating lavamoat policies
updating lavamoat after rebasing
policies
updating custom token warning and blocking detectedtoken link when tpken detection is off for supported networks
to update the token in fetchTosync
updating the contract map object
Revert build-system lavamoat policy changes
Move token list selection logic from components to getTokenList selector
updating the tokenList
Update lavamoat
Fix error
updating lavamoat
lint fix
fix unit test fail
fix unit test fail
lint fix
fixing rebase locale error
rebase fix
Revert build-system policy changes
temp
addressing review comments
* rebase fix
As we convert parts of the codebase to TypeScript, we will want a way to
track progress. This commit adds a dashboard which displays all of the
files that we wish to convert to TypeScript and which files we've
already converted.
The list of all possible files to convert is predetermined by walking
the dependency graph of each entrypoint the build system uses to compile
the extension (the files that the entrypoint imports, the files that the
imports import, etc). The list should not need to be regenerated, but
you can do it by running:
yarn ts-migration:enumerate
The dashboard is implemented as a separate React app. The CircleCI
configuration has been updated so that when a new commit is pushed, the
React app is built and stored in the CircleCI artifacts. When a PR is
merged, the built files will be pushed to a separate repo whose sole
purpose is to serve the dashboard via GitHub Pages (this is the same
way that the Storybook works). All of the app code and script to build
the app are self-contained under
`development/ts-migration-dashboard`. To build this app yourself, you
can run:
yarn ts-migration:dashboard:build
or if you want to build automatically as you change files, run:
yarn ts-migration:dashboard:watch
Then open the following file in your browser (there is no server
component):
development/ts-migration-dashboard/build/index.html
Finally, although you shouldn't have to do this, to manually deploy the
dashboard once built, you can run:
git remote add ts-migration-dashboard git@github.com:MetaMask/metamask-extension-ts-migration-dashboard.git
yarn ts-migration:dashboard:deploy
This is mainly associated with an update in GridPlus SDK and enables
better strategies for fetching calldata decoder data.
`eth-lattice-keyring` changes:
GridPlus/eth-lattice-keyring@v0.7.3...v0.10.0
`gridplus-sdk` changes (which includes a codebase rewrite):
GridPlus/gridplus-sdk@v1.2.3...v2.2.2
This reverts commit f09ab88891, reversing
changes made to effc761e0e.
This is being temporarily reverted to make it easier to release an
urgent fix for v10.15.1.
* lavamoat - apply lavamoat protections to popup and notification
* build - enable lavamoat for home
* lavamoat - add missing ui overrides for react family
* deps/patches - patch zxcvbn for ses compat
We currently store the JSON-RPC request and response objects in the permission activity log. The utility of doing this was always rather dubious, but never problematic. Until now.
In Flask, as the restricted methods have expanded in number, user secrets may be included on JSON-RPC message objects. This PR removes these properties from the permission activity log, and adds a migration which does the same to existing log objects. We don't interact with the log objects anywhere in our codebase, but we don't want unexpected properties to cause errors in the future should any log objects be retained.
This PR also updates relevant tests and test data. It makes a minor functional change to how a request is designated as a success or failure, but this should not change any behavior in practice.
An array of integers is now used to represent the SRP in three cases:
* In the import wallet flow, the UI uses it to pass the user-provided
SRP to the background (which converts the array to a buffer).
* In the create wallet flow, the UI uses it to retrieve the generated
SRP from the background.
* When persisting the wallet to state, the background uses it to
serialize the SRP.
Co-authored-by: Elliot Winkler <elliot.winkler@gmail.com>
Frederik Bolding
Alex Donesky
Dan Miller
Elliot Winkler
Mark Stacey
amerkadicE
George Marshall
Alex Miller
MetaMask Bot
Brad Decker
Maarten Zuidhoorn
Niranjana Binoy
Sam Gbafa
Daniel
kumavis
ryanml
Shane
Erik Marks