Overview
The v2 API uses session-based authentication. Log in via POST /auth/login; on success, a session is established and a CSRF token is issued.
State-changing requests (POST) require the X-Fess-CSRF-Token header. For information on how to obtain and rotate CSRF tokens, as well as the common response envelope and error model, see API Overview.
This page describes the following four endpoints:
Common User Information (UserPayload)
User information included in the responses of GET /auth/me and POST /auth/login is returned in the common UserPayload structure. All array fields are non-null; an empty array is returned when there are no values.
Fetching Authentication State
Request
| HTTP Method | GET |
| Endpoint | /api/v2/auth/me |
Retrieves the currently authenticated user. An anonymous call does not result in an error; it returns authenticated: false. When authenticated, user holds the UserPayload.
Response
On success (HTTP 200), the following response is returned in the common envelope format (example for authenticated user).
Each element of response is as follows:
| Field | Type | Description |
|---|---|---|
authenticated | boolean | Whether authenticated. (Required) |
user | object | UserPayload. Present only when authenticated is true. |
Error Response
Login
Request
| HTTP Method | POST |
| Endpoint | /api/v2/auth/login |
Logs in with a username and password. On successful login, the servlet session ID is rotated, a new CSRF token is issued, and the rate-limit buckets for the caller’s IP and the target user are cleared. If the rate limit is exceeded, a Retry-After header (in seconds) is included.
Even if a session is already authenticated, no short-circuit occurs; the provided credentials are always validated.
return_to must be a relative path matching ^/[A-Za-z0-9_\-/.?&=%:@+~#*!,;]*$. Additionally, protocol-relative paths (starting with //) and paths containing ASCII control characters are rejected and silently removed from the echoed response.
Note
This endpoint is exempt from CSRF validation (because no token exists before login).
Note
Unlike other state-changing endpoints, this endpoint consolidates oversized request bodies and unsupported Content-Type into 400 invalid_request (other endpoints return 413 / 415).
Request Body (LoginRequest)
Content-Type is application/json.
Request example:
Response
On success (HTTP 200, LoginResponse), the following response is returned in the common envelope format.
Each element of response is as follows:
| Field | Type | Description |
|---|---|---|
user | object | UserPayload. |
csrf_token | string | New CSRF token associated with the new session. (Required) |
return_to | string | Echoed only if the request value passed the allowlist. |
Error Response
Logout
Request
| HTTP Method | POST |
| Endpoint | /api/v2/auth/logout |
Logs out. This operation is idempotent; if there is no active session, it is a no-op and does not return an error. Always returns ok: true.
The X-Fess-CSRF-Token header is required.
Response
On success (HTTP 200, OkResponse), the following response is returned in the common envelope format.
Each element of response is as follows:
Error Response
Password Change
Request
| HTTP Method | POST |
| Endpoint | /api/v2/auth/password |
Changes the current user’s password. Validates current_password, applies the configured password policy to new_password, invalidates the current session, and returns re_login_required: true to prompt the SPA to redirect to the login page.
Since the session is destroyed server-side, csrf_token is not returned. The SPA must obtain a new token after re-authentication.
The X-Fess-CSRF-Token header is required.
Request Body (PasswordChangeRequest)
Content-Type is application/json.
Response
On success (HTTP 200), the following response is returned in the common envelope format.
Each element of response is as follows: