# _auth_handler · FT4 Rell API · Chromia Docs (concept)

> An auth handler defines who can and should call a specific operation. A new auth handler
should be defined for each operation in the dapp. See Also add_aut

Source: https://docs.chromia.com/pages/ft4-rell/-f-t4-library/lib.ft4.core.auth/_auth_handler/

STRUCT

# \_auth\_handler

An auth handler defines who can and should call a specific operation. A new auth handler
should be defined for each operation in the dapp.

**See Also**

* [add\_auth\_handler](https://docs.chromia.com/pages/ft4-rell/-f-t4-library/lib.ft4.core.auth/add_auth_handler/) — for a usage example

```signature
struct _auth_handler {
 flags: list<text>;
 message_formatter: (gtv) -> text?;
 resolver: (gtv, byte_array, list<byte_array>) -> byte_array??;
}
```

`flags: list<text>;`
:   The flags an auth descriptor should have to be authorized to call this operation.
    In this way, access levels can be defined, and a function can be setup in a way
    that calling it requires special permissions.

    By default, two flags are defined in FT4 operations:

    * `T` - Transfer. Everything that requires transferring assets requires this flag.
    * `A` - Account. Everything that modifies the account and its auth descriptors requires
      this flag

    If multiple flags appear here, an auth descriptor is required to have them all to be
    able to call the operation.

    No flags means any auth descriptor can be used.

    The `resolver` field of the auth handler might partially or completely override this
    field.

`message_formatter: (gtv) -> text?;`
:   A function that receives the the arguments of the operation and returns a message
    that should be signed if the signer that is authorizing is an EVM signer.

    This text will thus appear on the EVM wallet of the user to approve the operation.

    If null, a default message will be created by `generate_operation_auth_message`.
    It is suggested to only use the default messages in development environments.

    An example function that could be used as a message formatter is:

    Plain text

    ```
    operation send_chroma_tokens (amount: big_integer, account) { ... }
    function message_formatter_for_send_chroma_tokens (gtv) {
        val params = struct<send_chroma_tokens>.from_gtv(gtv);
        return "Do you want to send %s CHR to account %s?".format(
            params.amount,
            params.account
        );
    }
    ```

    The function can be as complex or simple as needed, and it can as well make no use
    of the gtv parameters by returning a default message in all cases - the message will
    have a nonce that prevents replay attacks.

`resolver: (gtv, byte_array, list<byte_array>) -> byte_array??;`
:   Either null, or a function that receives:

    * the arguments of the operation
    * the account ID
    * a list of auth descriptor IDs
      and returns the ID of the auth descriptor that should be used to authorize the
      operation, or null if none is acceptable.

    If this function is defined, it will be called by the client to pick the best auth
    descriptor to use between the ones that are available.

    If flags is not an empty list, it will be used to preselect which auth descriptors to
    pass to the resolver - otherwise, all auth descriptors can be passed, and the resolver
    could manually check flags if needed.

    This behavior allows the resolver to define cases in which one of the auth descriptors
    could call a certain operation with some flags, while a different auth descriptor needs
    a different flag to call the same operation.

[Source](https://gitlab.com/chromaway/ft4-lib/-/blob/development/rell/src/lib/ft4/core/auth/module.rell#lines-75)

[View this page on docs.chromia.com](https://docs.chromia.com/pages/ft4-rell/-f-t4%20-library/lib.ft4.core.auth/_auth_handler/index.html)Generated API reference, mirrored from the live docs