Authentication and roles
The API uses HTTP Basic authentication. Always put TLS in front of it; plain HTTP is for local demos only.
Credentials#
curl -su "instructor:demo" https://aarcv.example.mil/api/sortiesAccounts come from two places: users managed in the app by an administrator (Administration → Users, or POST /api/ops/users), and the AARCV_USERS environment variable (name:password:role,...). Passwords are stored as PBKDF2-SHA256 hashes with 200,000 iterations.
Role checks#
Each route enforces one of three kinds of check, shown in the Access badge on every API reference entry:
| Badge | Meaning |
|---|---|
| signed-in user | Any account. Product access still passes the release rules. |
| role: instructor or higher | Rank check. Instructor and administrator pass; maintainers, ML engineers and security officers sit at viewer rank for debrief routes. |
| permission: models | Named permission. See the table below. |
| Permission | Roles |
|---|---|
fleet | maintainer, admin |
maintenance | maintainer, instructor, ml_engineer, admin |
models | ml_engineer, admin |
aircrew | instructor, admin |
security | security_officer, admin |
redact | instructor, security_officer, admin |
users, config | admin |
Errors#
| Status | When |
|---|---|
| 401 | Missing or wrong credentials. |
| 403 | Role or permission check failed, or a release rule denied a product. The body names the rule. |
| 404 | Unknown sortie or product. |
| 409 | The request conflicts with security policy, for example an upload that would exceed the network ceiling. |
| 422 | Validation error; the body lists the fields. |
Audit#
Every upload, review, release decision, export, denial and administrative change is written to the hash-chained audit log with the acting account.
Was this page helpful?