# Registration and Login Input Policy

    This policy is for the website agent and describes the input rules enforced by
    the API. The agent must validate inputs before submitting them and must never
    silently change a user’s password.

    ## Registration

    Registration accepts these required fields:

    | Field | Rules |
    | --- | --- |
    | `name` | Required; 1–100 characters after trimming. |
    | `username` | Required; 1–50 characters after trimming; must not contain whitespace. |
    | `email` | Required; 1–254 characters after trimming; converted to lowercase; must not contain whitespace; must match a standard `name@domain.tld`-style format. |
    | `password` | Required; 1–128 characters; whitespace is preserved. |

    The registration password must also:

    - Be at least 12 characters long.
    - Contain at least one lowercase letter, one uppercase letter, one number, and one special character.
    - Not contain the username or the email’s local part.
    - Not be an obvious common password, including `password`, `password123`, `qwerty`, `letmein`, `welcome`, `admin`, `iloveyou`, `monkey`, `dragon`, or `abc123`.
    - Not contain three identical characters in a row.
    - Not contain obvious sequential patterns such as `1234`, `2345`, `6789`, or `abcd`.
    - Not belong to a disposable or temporary email address.

    ## Login

    Login accepts only `email` and `password`:

    - Both fields are required and may contain 1–254 characters for email and 1–128 characters for password.
    - Email is trimmed, converted to lowercase, and must not contain whitespace.
    - Email must pass the same `name@domain.tld`-style format check used during registration.
    - Password whitespace is preserved; the password must be submitted exactly as entered during registration.
    - Registration-only password complexity checks and disposable-email checks are not repeated during login.

    The agent must not trim, lowercase, or otherwise transform the password. The
    API removes control characters from input values; ordinary password whitespace
    is intentionally retained.

    ## Invalid input and authentication failures

    - Do not submit a form until all applicable client-side rules pass.
    - If the API returns HTTP `400`, show the validation message and let the user correct the input.
    - If login returns HTTP `401`, show a generic “Invalid email or password” message. Do not reveal whether the email exists.
    - Never log or expose passwords, password hashes, salts, or authentication tokens.
    - Unexpected server failures must be shown as a generic failure message and retried only when appropriate; do not expose database or stack-trace details.

    The API remains the authoritative validator. Client-side validation improves the
    user experience but must not replace server-side validation.