msg․sender Considered Harmful
One question that every Solidity user asks when they start programming in Cadence is
"How do I get the account who authorized the transaction?"
In the Ethereum world, this account is referred to as
On Ethereum, checking
msg.sender is used to modify a function's behaviour depending on who authorized it.
Doing so is key to identity, permissions, ownership and security on Ethereum.
Cadence does not have
msg.sender and there is no transaction-level way
for Cadence code to uniquely identify its caller,
not least because each transaction can be signed by more than one account.
This then translates to the transaction having access to all of the signers' accounts. A further difference from Ethereum is that while Ethereum and Flow both have accounts that can contain contract code and data, in Cadence the resources that individual users own (such as NFTs) are placed in the user account's storage area rather than the contract account's.
All of this means that a task that would be implemented
by a single central contract checking
msg.sender in Solidity
will require a different approach in Cadence. The design of Cadence is intentionally different;
it follows a Capability-based security model
instead of an Access-Control List-based model.
This design offers distinct advantages for code robustness and security.
This article describes how to perform some common tasks in idiomatic ways that use those advantages and also describes some ways of approaching the same tasks that should be avoided.
Admin facilities should be contained in Admin resources. This can be a single resource with capabilities to it provided through different interfaces to expose different functionality for different roles, or it can be different resources for each role.
This is described in the Design Patterns document:
A good example of this is minting tokens:
Where access to admin functionality must be given to several different accounts and/or be revocable, the Capability Receiver pattern supports this.
This is described in the Patterns document:
Limiting a user's control of resources that they own except in exceptional circumstances
is considered un-Flow-like. If you must implement allow/block listing of accounts
for regulatory compliance, route calls from functions in your resources
access(contract) code on their contract that checksan admin-controlled dictionary
containing the information required to check for allowed or blocked accounts.
This code could check the resource owner, but doing so is an antipattern (see below)
and should not be used as it cannot be relied on. It is better to use an object's
It is important to note that the uuid does not identify the owner, and that resources can be transferred to different owners, and moved to a different path within the same user's storage or replaced by a different resource at the same path.
Giving another user temporary partial control of resources should be implemented via private capabilities.
Limiting access to the correct resources can be achieved by (e.g.) creating a new Vault containing only the allowance amount, or creating a new Collection containing only the NFTs that the other user is the operator for.
Limiting access to the correct functionality can be achieved by providing the other user with a capability constrained to the desired interface.
The capability can be revoked to remove the ability when required.
Alternatively, a capability on the original resource (Vault, Collection, etc.) can be wrapped in a resource that enforces all of these limits, and then this (or, preferably, a capability to it) passed to the other user.
For example, see KittyItemsMarket's carefully constrained use of a NonFungibleToken.Provider:
If an account's storage contains a resource (such as an NFT, and NFT Collection, or an FT Vault), that account owns it. There is no need to record this anywhere else. It can be checked through public capabilities. If the user removes the public capabilities, that is their choice.
For example the Collection resource in the NFT standard, its interfaces, and the Capabilities to it placed in a user's storage:
Custodial NFT marketplaces have temporary ownership of a resource. They should provide the ability to identify the token's original owner and to return it to them if it is not sold.
User profiles can be implemented as resources placed in the storage of the user's account, with read access via a public capability.
Admin control of user profiles, where appropriate, can be implemented using private capabilities,
access(contract) code, or using types within the contract that can only be created
by the admin as function arguments.
Contracts have the member variable
let account: Account,
which is the account in which the contract is deployed:
This is of limited use in replacing
msg.sender, as it is essentially a tautology on Flow
because contracts are deployed to the account to which you deploy them.
Resources that are in storage (but not those that are located in-memory,
e.g. when a resource has just been created) have the implicit field
let owner: PublicAccount?
This can be defeated by using a newly created resource, as the owner will then be nil.