website: format docs with prettier (#2833)

* run prettier

Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org>

* add scim to comparison

Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org>
This commit is contained in:
Jens L
2022-05-09 21:22:41 +02:00
committed by GitHub
parent 26d92d9259
commit f9469e3f99
148 changed files with 3447 additions and 3107 deletions

View File

@ -33,10 +33,7 @@ Below is the response, for example for an Identification stage.
"component": "ak-stage-identification",
// Stage-specific fields
"user_fields": [
"username",
"email"
],
"user_fields": ["username", "email"],
"password_fields": false,
"primary_action": "Log in",
"sources": []

View File

@ -4,7 +4,6 @@ title: Websocket API
authentik has two different WebSocket endpoints, one is used for web-based clients to get real-time updates, and the other is used for outposts to report their healthiness.
### Web `/ws/client/`
:::info
@ -34,15 +33,15 @@ Authentication is done via the `Authorization` header, same as the regular API.
All messages have two fields, `instruction` and `args`. Instruction is any number from this list:
- `0`: ACK, simply acknowledges the previous message
- `1`: HELLO, used for monitoring and regularly sent by outposts
- `2`: TRIGGER_UPDATE, sent by authentik to trigger a reload of the configuration
- `0`: ACK, simply acknowledges the previous message
- `1`: HELLO, used for monitoring and regularly sent by outposts
- `2`: TRIGGER_UPDATE, sent by authentik to trigger a reload of the configuration
Arguments for these messages vary, all though these common args are always sent:
- `args['uuid']`: A unique UUID generated on startup of an outpost, used to uniquely identify it.
- `args['uuid']`: A unique UUID generated on startup of an outpost, used to uniquely identify it.
These fields are only sent for HELLO instructions:
- `args['version']`: Version of the outpost
- `args['buildHash']`: Build hash of the outpost, when available
- `args['version']`: Version of the outpost
- `args['buildHash']`: Build hash of the outpost, when available

View File

@ -7,19 +7,19 @@ the documentation is easy to read and uses similar phrasing.
# General guidelines
- authentik should always be stylized as `authentik` (with a lower-case a and ending with a k)
- Documentation should use American english
- Feel free to use Docusaurus-specific features, see [here](https://docusaurus.io/docs/next/markdown-features)
- Use abbreviations where it makes sense (for commonly used terms like SAML and OAuth)
- Phrasing should never blame the user, and should be subjective, i.e
- authentik should always be stylized as `authentik` (with a lower-case a and ending with a k)
- Documentation should use American english
- Feel free to use Docusaurus-specific features, see [here](https://docusaurus.io/docs/next/markdown-features)
- Use abbreviations where it makes sense (for commonly used terms like SAML and OAuth)
- Phrasing should never blame the user, and should be subjective, i.e
- **DON'T** `You may never click x.`
- **DO** `x should never be clicked.`
- **DON'T** `You may never click x.`
- **DO** `x should never be clicked.`
- When referring to other objects in authentik, use _cursive_ text, and link to the corresponding documentation if possible.
- When referring to external tools, give an example how to use the tools or explain how the user can use them.
- Make sure to add the documentation to add to the sidebar, if adding a new page.
- Test how the documentation renders using the Netlify Preview, especially when using Docusaurus-specific features.
- When referring to other objects in authentik, use _cursive_ text, and link to the corresponding documentation if possible.
- When referring to external tools, give an example how to use the tools or explain how the user can use them.
- Make sure to add the documentation to add to the sidebar, if adding a new page.
- Test how the documentation renders using the Netlify Preview, especially when using Docusaurus-specific features.
If you find any documentation that doesn't match these guidelines, feel free to either open an Issue or a PR so they can be fixed.
@ -27,12 +27,12 @@ If you find any documentation that doesn't match these guidelines, feel free to
These guidelines apply in addition to the ones above.
- For placeholders, use angle brackets (`<placeholder-name>`).
- For placeholders, use angle brackets (`<placeholder-name>`).
Make sure to also define if the placeholder is something the user needs to define, something another system defines, or randomly generated.
If you're adding configuration snippets to the documentation, and the snippet is in a language that supports comments,
other placeholders may be used, for example comments referencing an earlier step.
- For placeholder domains, use `authentik.company` and `app-name.company`, where `app-name` is the name of the application you are writing documentation for.
- Try to order the documentation in the order that makes it easiest for the user to configure.
- For placeholder domains, use `authentik.company` and `app-name.company`, where `app-name` is the name of the application you are writing documentation for.
- Try to order the documentation in the order that makes it easiest for the user to configure.

View File

@ -4,4 +4,3 @@ slug: /
---
Welcome to the authentik developer documentation. authentik is fully open source and can be found here: https://github.com/goauthentik/authentik

View File

@ -6,9 +6,9 @@ If you want to only make changes on the UI, you don't need a backend running fro
### Prerequisites
- Node (any recent version should work, we use 16.x to build)
- Make (again, any recent version should work)
- Docker and docker-compose
- Node (any recent version should work, we use 16.x to build)
- Make (again, any recent version should work)
- Docker and docker-compose
### Instructions
@ -28,15 +28,15 @@ If you want to only make changes on the UI, you don't need a backend running fro
4. Add this volume mapping to your compose file
```yaml
version: '3.2'
version: "3.2"
services:
# [...]
server:
# [...]
volumes:
- ./web:/web
- ./local.env.yml:/local.env.yml
server:
# [...]
volumes:
- ./web:/web
- ./local.env.yml:/local.env.yml
```
This makes the local web files and the config file available to the authentik server.

View File

@ -8,11 +8,11 @@ To create a local development setup for authentik, you need the following:
### Requirements
- Python 3.10
- poetry, which is used to manage dependencies, and can be installed with `pip install poetry`
- Go 1.18
- PostgreSQL (any recent version will do)
- Redis (any recent version will do)
- Python 3.10
- poetry, which is used to manage dependencies, and can be installed with `pip install poetry`
- Go 1.18
- PostgreSQL (any recent version will do)
- Redis (any recent version will do)
For PostgreSQL and Redis, you can use the docker-compose file in `scripts/`. You can also use a native install, if you prefer.
@ -28,7 +28,7 @@ To configure authentik to use the local databases, create a file in the authenti
```yaml
debug: true
postgresql:
user: postgres
user: postgres
log_level: debug
secret_key: "A long key you can generate with `pwgen 40 1` for example"

View File

@ -18,9 +18,9 @@ To simplify translation you can use https://www.transifex.com/beryjuorg/authenti
### Prerequisites
- Node (any recent version should work, we use 16.x to build)
- Make (again, any recent version should work)
- Docker
- Node (any recent version should work, we use 16.x to build)
- Make (again, any recent version should work)
- Docker
Run `npm i` in the `/web` folder to install all dependencies.