Repository navigation
Fix restricted Snap method implementations - #150
Conversation
| export type ConfirmMethodHooks = { | ||
| /** | ||
| * | ||
| * @param snapId - The ID of the Snap that created the confirmation. |
There was a problem hiding this comment.
Is a "snapId" the same thing as an "origin"?
There was a problem hiding this comment.
Ah, yes. We need some terminology cleanup to happen after launch. In RPC-method-land, origin and snapId are used interchangeably. Probably we'll move to subjectIdentifier or something like that?
There was a problem hiding this comment.
What will the snap ID be? Could it be expressed as an origin? We could just use origin
There was a problem hiding this comment.
We could perhaps use an origin, but in #140 I decided to encode the publishing location of the Snap in the ID itself to make it easy to do stuff like this: https://github.com/MetaMask/snaps-skunkworks/blob/snap-publishing-v0.1/packages/controllers/src/snaps/SnapController.ts/#L932-L939
Following #132, restricted methods can no longer be bound to the requesting origin. Instead, they receive a single object parameter with an object property `context`, which in turn has a string property `origin` that identifies the the subject that made the request. This PR ensures that all restricted method hooks use `context.origin` where necessary instead of assuming that they are bound to the requesting origin.
Following #132, restricted methods can no longer be bound to the requesting origin. Instead, they receive a single object parameter with an object property
context, which in turn has a string propertyoriginthat identifies the the subject that made the request.This PR ensures that all restricted method hooks use
context.originwhere necessary instead of assuming that they are bound to the requesting origin.