mirror of
https://github.com/zkldi/Tachi.git
synced 2026-09-26 00:47:57 +03:00
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
45 lines
1.6 KiB
Markdown
45 lines
1.6 KiB
Markdown
# Client File Flow
|
|
|
|
While we have an [OAuth2 Flow](./oauth2.md), that requires another webserver.
|
|
What if you just want an API key to throw inside a config file? This is a
|
|
common use case.
|
|
|
|
For this, we have the Client File Flow. This flow is entirely done on our
|
|
site, and results in the user downloading a file, or copying a string.
|
|
|
|
## Outline
|
|
|
|
!!! note
|
|
This documentation uses `boku.tachi.ac` as the example site. You should
|
|
replace this with the instance of Tachi you're pointing against, if it
|
|
is different.
|
|
|
|
- You navigate the user to `https://boku.tachi.ac/client-file-flow/YOUR_CLIENT_ID`.
|
|
- They are asked if they want to create an API Key for your client.
|
|
- If they select yes, an API Key is created for your client, and depending on your client parameters, they get it.
|
|
|
|
|
|
## Download Format
|
|
|
|
When you create a Tachi API Client, you can select the `File Template` parameter. This will change the format of the key given to the user.
|
|
|
|
For example, Let's say you wanted the user to download a `.json` file with
|
|
your token.
|
|
|
|
You could set a template of something like:
|
|
|
|
```json
|
|
{
|
|
"tachi-api-token": "%%TACHI_KEY%%",
|
|
"someOtherField": "foo"
|
|
}
|
|
```
|
|
|
|
If the `File Template` is not set, it is just output normally, without any templating.
|
|
|
|
The first instance of `%%TACHI_KEY%%` will be replaced with the generated API key.
|
|
|
|
The other file parameter you control is the `File Name`. If this is set, the user will be presented with a button that will download the above content.
|
|
|
|
If it is not set, the contents of the template are shown in browser, and the user will have to copy-paste the API Key.
|