zk
e363bd2532
* docs: migrate from mkdocs to mdbook - Rename old mkdocs docs/ to old-docs/ for reference - Set up new docs/ with mdbook (book.toml + src/ tree) - Mirror full nav structure from mkdocs.yml into SUMMARY.md - Add Justfile-docs with docs-serve, docs-build, docs-check, docs-install recipes - Import Justfile-docs from root Justfile - Rewrite .github/workflows/docs.yml: build step uses taiki-e/install-action to install mdbook, split into separate build + deploy jobs, PR builds run the check step too * ci(docs): pin actions to SHAs, install mdbook via release binary * ci(docs): install mdbook from apt instead of curling a release binary * dev: replace mkdocs python stack with mdbook in dev image * ci(docs): apt only works on Debian; restore release binary install for Ubuntu CI * docs: fix duplicate file entries in SUMMARY.md * docs: remove docs-install recipe * docs: remove site-url from book.toml to fix asset loading * dev: install mdbook from upstream release binary, not Debian apt The Debian package (0.4.x+ds) strips bundled font assets, leaving the built site without fonts/fonts.css. Use the upstream tarball (same as CI) so the theme is complete. Handles x86_64 and aarch64. * docs: vendor mdbook tarballs in dev/mdbook/, install from there Dockerfile.dev uses COPY + tar to install the right arch at build time. CI extracts the x86_64 tarball directly from the checkout. No network access required for either — and no stripped-fonts Debian package. * fix: unwritten
2.3 KiB
API Authorisation
Certain endpoints on the Tachi API require permissions. This page covers how to present your permissions to the server, and what those permissions are.
Authorising Requests
There are two ways to authorise a request. The first one involves API keys.
Token Authentication
To use authentication with a request, you should set a HTTP header of:
Authorization: Bearer API_KEY
Where API_KEY is the API key you wish to use.
Self-Key Authentication
The other way to authorise a request is with your session cookie. This MUST NOT be used by code, and is instead a way for logged-in users to interact with the API as themselves.
To use authentication in this way, simply make a request with your Kamaitachi_SESSION or
Bokutachi_SESSION cookie.
The reason for this second authentication method is so that, when a user logs in, they can use the cookie they were set to also interact with the API.
This type of authentication is referred to as "Self-Key" or "Session-Key" authentication, and it grants special permissions over API Tokens, such as being able to change your password.
Getting Tokens
You should make a Tachi API Client. With that, you can use our OAuth2 Flow, or our Client File Flow.
Permissions
An API key does not implicitly have permission to do anything on a users behalf for security reasons.
Some endpoints require specific permissions, such as a score_submit permission for submitting scores.
!!! warning API keys can not have their permissions altered once set, a new key must be generated.
!!! info Cookie-based authentication always has all permissions for the user.
Table Of Permissions
The table of permissions is as follows.
| Permission | Description |
| :: | :: |
| submit_score | Perform requests that could submit scores for the user. |
| customise_profile | Perform requests that could modify user info, like their status or about me. |
| customise_session | Perform requests that could modify the users sessions, such as changing their names. |
| customise_score | Perform requests that could modify a users scores, such as adding a comment. |
| delete_score | Perform requests that could delete scores for that user. |