What are the differences between is_signer AccountInfo property, Signer type and signer constraint

Question

what is the difference between signer constraint:

Checks the given account signed the transaction.
Custom errors are supported via @.
Consider using the Signer type if you would only have this constraint on the account.

Example:

#[account(signer)]
pub authority: AccountInfo<'info>,
#[account(signer @ MyError::MyErrorCode)]
pub payer: AccountInfo<'info>

and

pub struct AccountInfo<'a> {
    pub key: &'a Pubkey,
    pub is_signer: bool,
    pub is_writable: bool,
    pub lamports: Rc<RefCell<&'a mut u64>>,
    pub data: Rc<RefCell<&'a mut [u8]>>,
    pub owner: &'a Pubkey,
    pub executable: bool,
    pub rent_epoch: Epoch,
}

is_signer property on AccountInfo?

is_signer: bool Was the transaction signed by this account’s public key?

and then we have also Signer type instead of AccountInfo

pub struct Signer<'info> { /* private fields */ } Type validating that the account signed the transaction. No other ownership or type checks are done. If this is used, one should not try to access the underlying account data.

Answer 1

The is_signer field in an AccountInfo struct indicates that the account has signed the transaction/instruction from the client. It can only be set client-side and the on-chain code checks this to see if it has rights.

Both Signer<'info> and #[account(signer)] do the same thing: They enforce that an account has actually signed the instruction from the client by ensuring that the is_signer field of the account is set to true.

The slight difference between both is that Signer is a wrapper around AccountInfo and essentially the same as:

#[account(signer)]
AccountInfo<'info>

This means that when you use it, you're stating that no other type checks are needed.

The #[account(signer)] attribute on the other hand is more flexible and can be used with different type checks and ownership constraints i.e:

#[account(mut, signer, has_one = ...)
Account<'info, State>