AutoBE
    Preparing search index...

    Interface IAuthorization

    Authorization - Authentication and user type information

    This field defines how the API authenticates the request and restricts access to specific user types.

    ✅ Only the Authorization HTTP header is used for authentication. The expected format is:

    Authorization: Bearer <access_token>

    The token must be a bearer token (e.g., JWT or similar), and when parsed, it is guaranteed to include at least the authenticated actor's id field. No other headers or cookie-based authentication methods are supported.

    interface IAuthorization {
        description: string;
        name: string & CamelPattern;
    }
    Index

    Properties

    description name

    Properties

    description: string

    Detailed description of the authorization role

    Provides a comprehensive explanation of:

    • The purpose and scope of this authorization role
    • Which types of users are granted this role
    • What capabilities and permissions this role enables
    • Any constraints or limitations associated with the role
    • How this role relates to the underlying database schema
    • Examples of typical use cases for this role

    This description should be detailed enough for both API consumers to understand the role's purpose and for the system to properly enforce access controls.

    MUST be written in English. Never use other languages.

    name: string & CamelPattern

    Allowed user types for this API

    Specifies which user types are permitted to access this API.

    This is not a permission level or access control role. Instead, it describes who the user is — their type within the service's domain model. It must correspond 1:1 with how the user is represented in the database.

    MUST use camelCase naming convention.

    ⚠️ Important: Each role must exactly match a table name defined in the database schema. This is not merely a convention or example — it is a strict requirement.

    A valid role must meet the following criteria:

    • It must uniquely map to a user group at the database level, represented by a dedicated table.
    • It must not overlap semantically with other roles — for instance, both admin and administrator must not exist to describe the same type.

    Therefore, if a user type cannot be clearly and uniquely distinguished in the database, It cannot be used as a valid role here.

    Settings

    Member Visibility

    On This Page

    Properties