# Permission System 2.0
## Background
This PR migrates the extension permission system to [the new `PermissionController`](https://github.com/MetaMask/snaps-skunkworks/tree/main/packages/controllers/src/permissions).
The original permission system, based on [`rpc-cap`](https://github.com/MetaMask/rpc-cap), introduced [`ZCAP-LD`](https://w3c-ccg.github.io/zcap-ld/)-like permissions to our JSON-RPC stack.
We used it to [implement](https://github.com/MetaMask/metamask-extension/pull/7004) what we called "LoginPerSite" in [version 7.7.0](https://github.com/MetaMask/metamask-extension/releases/tag/v7.7.0) of the extension, which enabled the user to choose which accounts, if any, should be exposed to each dapp.
While that was a worthwhile feature in and of itself, we wanted a permission _system_ in order to enable everything we are going to with Snaps.
Unfortunately, the original permission system was difficult to use, and necessitated the creation of the original `PermissionsController` (note the "s"), which was more or less a wrapper for `rpc-cap`.
With this PR, we shake off the yoke of the original permission system, in favor of the modular, self-contained, ergonomic, and more mature permission system 2.0.
Note that [the `PermissionController` readme](https://github.com/MetaMask/snaps-skunkworks/tree/main/packages/controllers/src/permissions/README.md) explains how the new permission system works.
The `PermissionController` and `SubjectMetadataController` are currently shipped via `@metamask/snap-controllers`. This is a temporary state of affairs, and we'll move them to `@metamask/controllers` once they've landed in prod.
## Changes in Detail
First, the changes in this PR are not as big as they seem. Roughly half of the additions in this PR are fixtures in the test for the new migration (number 68), and a significant portion of the remaining ~2500 lines are due to find-and-replace changes in other test fixtures and UI files.
- The extension `PermissionsController` has been deleted, and completely replaced with the new `PermissionController` from [`@metamask/snap-controllers`](https://www.npmjs.com/package/@metamask/snap-controllers).
- The original `PermissionsController` "domain metadata" functionality is now managed by the new `SubjectMetadataController`, also from [`@metamask/snap-controllers`](https://www.npmjs.com/package/@metamask/snap-controllers).
- The permission activity and history log controller has been renamed `PermissionLogController` and has its own top-level state key, but is otherwise functionally equivalent to the existing implementation.
- Migration number 68 has been added to account for the new state changes.
- The tests in `app/scripts/controllers/permissions` have been migrated from `mocha` to `jest`.
Reviewers should focus their attention on the following files:
- `app/scripts/`
- `metamask-controller.js`
- This is where most of the integration work for the new `PermissionController` occurs.
Some functions that were internal to the original controller were moved here.
- `controllers/permissions/`
- `selectors.js`
- These selectors are for `ControllerMessenger` selector subscriptions. The actual subscriptions occur in `metamask-controller.js`. See the `ControllerMessenger` implementation for details.
- `specifications.js`
- The caveat and permission specifications are required by the new `PermissionController`, and are used to specify the `eth_accounts` permission and its JSON-RPC method implementation.
See the `PermissionController` readme for details.
- `migrations/068.js`
- The new state should be cross-referenced with the controllers that manage it.
The accompanying tests should also be thoroughly reviewed.
Some files may appear new but have just moved and/or been renamed:
- `app/scripts/lib/rpc-method-middleware/handlers/request-accounts.js`
- This was previously implemented in `controllers/permissions/permissionsMethodMiddleware.js`.
- `test/mocks/permissions.js`
- A truncated version of `test/mocks/permission-controller.js`.
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
* add metametrics wrapper
* add history dep
* provide test data and mock react router
* add first confirmaion screen
* figure out a way to mock match.params
* render token approval with data
* fix lockfile
* fix lint
* remove use effect
* lintfix
* add . for src paths
* litfix
* Add knobs to change redux store for confirm-approve component (Storybook) (#11135)
* add knob for domain
* knobify
* remove logs
* remove comment
* lintfix
* fix comments
* add background calls + metriccs event to storybook acctions
* lintfixxxx
Our Storybook dependencies have been updated to v6.1.9, from v5. This
was done to address a security vulnerability in a transitive dependency
of these packages (`highlight.js`).
The primary changes required by this Storybook update were the change
in import path for the `withKnobs` hook, the change in background
config format, and the webpack configuration. Storybook seems to work
correctly.
The migration was guided by the Storybook changelog[1] and the
Storybook v6 migration guide[2].
There is one Storybook error remaining; it fails to load the Euclid
font. This is a pre-existing error though, so we can fix it in a later
PR.
The `yarn.lock` file was deduplicated in this PR as well, as it was
required to fix various install warnings that were introduced with this
update.
[1]: https://github.com/storybookjs/storybook/blob/next/CHANGELOG.md
[2]: https://github.com/storybookjs/storybook/blob/next/MIGRATION.md
This updates the `copy-webpack-plugin` to the latest published version, 6.0.3,
resolving [a high-severity security advisory][1] with its `serialize-javascript`
dependency.
[1]: https://www.npmjs.com/advisories/1548
See https://www.npmjs.com/advisories/1548 for more information.
The `yarn audit` output:
```
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ high │ Remote Code Execution │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ serialize-javascript │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in │ >=3.1.0 │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ copy-webpack-plugin │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ copy-webpack-plugin > serialize-javascript │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ https://www.npmjs.com/advisories/1548 │
└───────────────┴──────────────────────────────────────────────────────────────┘
```
The relevant [`v6.0.0`][2] breaking changes:
- minimum supported Node.js version is 10.13
- ✅ We use 10.18.1 locally and on CI
- the plugin now accepts an object, you should change `new CopyPlugin(patterns, options)` to `new CopyPlugin({ patterns, options })`
- ✅ Updated `.storybook/webpack.config.js`
[2]:https://github.com/webpack-contrib/copy-webpack-plugin/releases/tag/v6.0.0
A `Menu` component has been extracted from the
`ConnectedAccountsListOptions` component. The menu and the menu items
are now the `Menu` and `MenuItem` components respectively.
A custom body was added to the Storybook preview to ensure that the
`popover-content` element was present in the DOM before the Menu was
constructed.
The Font Awesome font wasn't loaded correctly in the Storybook build.
Unlike our other fonts, Font Awesome is copied from `node_modules` at
build-time rather than being saved directly in `app/fonts`.
The `copy-webpack-plugin` plugin is now used in the Storybook webpack
build to copy the fonts explicitly from `node_modules` into the build
output directory. The font now seems to load correctly in Storybook.
Various SVGs were being imported directly in components using Webpack
loaders. This was done to get these components to work correctly in
storybook, which uses Webpack. However we don't use Webpack for our
actual build system, so these components would fail when you attempted
to use them.
Instead the storybook script has been updated to use the `--static-dir`
flag, which allows specifying a directory of files to serve statically.
The `app` directory is served statically, so all of the relative URLs
we use in practice to reference fonts and images should just work.
The storybook build command has been updated to use the same flag.
Unfortunately this also means that the uncompiled background code is
now included in the build as well, because it's alongside our static
files. This shouldn't have any impact upon the build though.
The use of this `static-dir` option as made much of the existing
storybook Webpack configuration unnecessary, so it has been reduced to
just the essential steps.
