-
-
Notifications
You must be signed in to change notification settings - Fork 195
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor(permission-controller): Rationalize permission and caveat validation #5062
Conversation
|
||
// We do not need to validate caveats in this case, because the plain | ||
// permission constructor function does not modify the caveats, which | ||
// were already validated by `constructCaveats` above. | ||
performCaveatValidation = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're all trying to find the guy who introduced this futile and brittle "optimization".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
…lidation
8d7dbed
to
2422ce2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - have verified that Snaps doesn't use permission validators to validate caveat contents too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Explanation
Via discussion during MetaMask/metamask-extension#27847, it became apparent that there was confusion re: the purpose of permission vs. caveat validators and when to use one vs. the other. This has now been properly documented in multiple places in the permission controller package.
In addition, the permission controller implementation contained some irregularities regarding its own permission validation logic. This surfaced in the form of redundant permission and caveat validator calls, both of which have now been removed. (In addition, one overly complicated "optimization" to avoid redundant caveat validator calls has been removed.)
Reviewers: although I doubt it's a problem, we should take care to ensure that we weren't relying on the old behavior in any of our existing caveat or permission specifications.
References
Changelog
@metamask/permission-controller
ARCHITECTURE.md
.Checklist