website: Use Docusaurus Frontmatter for badges (#12893)
website/docs: Reduce redundant usage of badges. Move badge logic to components. - Fix JSX class name warning. - Remove duplicate titles. - Flesh out `support_level` frontmatter.
This commit is contained in:
@ -2,7 +2,7 @@
|
||||
title: Export
|
||||
---
|
||||
|
||||
## Global export <span class="badge badge--version">authentik 2022.8.2+</span>
|
||||
## Global export
|
||||
|
||||
To migrate existing configurations to blueprints, run `ak export_blueprint` within any authentik Worker container. This will output a blueprint for most currently created objects. Some objects will not be exported as they might have dependencies on other things.
|
||||
|
@ -2,10 +2,6 @@
|
||||
title: Blueprints
|
||||
---
|
||||
|
||||
<span class="badge badge--version">authentik 2022.8+</span>
|
||||
|
||||
---
|
||||
|
||||
Blueprints offer a new way to template, automate and distribute authentik configuration. Blueprints can be used to automatically configure instances, manage config as code without any external tools, and to distribute application configs.
|
||||
|
||||
## Types
|
||||
@ -58,7 +54,7 @@ To push a blueprint to an OCI-compatible registry, [ORAS](https://oras.land/) ca
|
||||
oras push ghcr.io/<username>/blueprint/<blueprint name>:latest <yaml file>:application/vnd.goauthentik.blueprint.v1+yaml
|
||||
```
|
||||
|
||||
## Storage - Internal <span class="badge badge--version">authentik 2023.1+</span>
|
||||
## Storage - Internal
|
||||
|
||||
Blueprints can be stored in authentik's database, which allows blueprints to be managed via external configuration management tools like Terraform.
|
||||
|
@ -4,7 +4,7 @@ Some models behave differently and allow for access to different API fields when
|
||||
|
||||
## `authentik_core.token`
|
||||
|
||||
### `key` <span class="badge badge--version">authentik 2023.4+</span>
|
||||
### `key`
|
||||
|
||||
Via the standard API, a token's key cannot be changed, it can only be rotated. This is to ensure a high entropy in it's key, and to prevent insecure data from being used. However, when provisioning tokens via a blueprint, it may be required to set a token to an existing value.
|
||||
|
||||
@ -26,7 +26,7 @@ For example:
|
||||
|
||||
## `authentik_core.user`
|
||||
|
||||
### `password` <span class="badge badge--version">authentik 2023.6+</span>
|
||||
### `password`
|
||||
|
||||
Via the standard API, a user's password can only be set via the separate `/api/v3/core/users/<id>/set_password/` endpoint. In blueprints, the password of a user can be set using the `password` field.
|
||||
|
||||
@ -45,7 +45,7 @@ For example:
|
||||
password: this-should-be-a-long-value
|
||||
```
|
||||
|
||||
### `permissions` <span class="badge badge--version">authentik 2024.8+</span>
|
||||
### `permissions`:ak-version[2024.8]
|
||||
|
||||
The `permissions` field can be used to set global permissions for a user. A full list of possible permissions is included in the JSON schema for blueprints.
|
||||
|
||||
@ -63,7 +63,7 @@ For example:
|
||||
|
||||
## `authentik_core.application`
|
||||
|
||||
### `icon` <span class="badge badge--version">authentik 2023.5+</span>
|
||||
### `icon`
|
||||
|
||||
Application icons can be directly set to URLs with the `icon` field.
|
||||
|
||||
@ -81,7 +81,7 @@ For example:
|
||||
|
||||
## `authentik_sources_oauth.oauthsource`, `authentik_sources_saml.samlsource`, `authentik_sources_plex.plexsource`
|
||||
|
||||
### `icon` <span class="badge badge--version">authentik 2023.5+</span>
|
||||
### `icon`
|
||||
|
||||
Source icons can be directly set to URLs with the `icon` field.
|
||||
|
||||
@ -99,7 +99,7 @@ For example:
|
||||
|
||||
## `authentik_flows.flow`
|
||||
|
||||
### `icon` <span class="badge badge--version">authentik 2023.5+</span>
|
||||
### `icon`
|
||||
|
||||
Flow backgrounds can be directly set to URLs with the `background` field.
|
||||
|
||||
@ -119,7 +119,7 @@ For example:
|
||||
|
||||
## `authentik_rbac.role`
|
||||
|
||||
### `permissions` <span class="badge badge--version">authentik 2024.8+</span>
|
||||
### `permissions`:ak-version[2024.8]
|
||||
|
||||
The `permissions` field can be used to set global permissions for a role. A full list of possible permissions is included in the JSON schema for blueprints.
|
||||
|
@ -4,7 +4,7 @@ To use the custom tags with your preferred editor, you must make the editor awar
|
||||
|
||||
For VS Code, for example, add these entries to your `settings.json`:
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"yaml.customTags": [
|
||||
"!Condition sequence",
|
||||
@ -301,7 +301,7 @@ The above example will resolve to something like this:
|
||||
- "bar: (index: 2, letter: r)"
|
||||
```
|
||||
|
||||
#### `!AtIndex` <span class="badge badge--version">authentik 2024.12+</span>
|
||||
#### `!AtIndex`:ak-version[2024.12]
|
||||
|
||||
Minimal example:
|
||||
|
@ -42,7 +42,7 @@ ak_message("Access denied")
|
||||
return False
|
||||
```
|
||||
|
||||
import Functions from "../../expressions/_functions.md";
|
||||
import Functions from "../../expressions/_functions.mdx";
|
||||
|
||||
<Functions />
|
||||
|
||||
@ -119,7 +119,7 @@ This includes the following:
|
||||
- `context['prompt_data']`: Data which has been saved from a prompt stage or an external source. (Optional)
|
||||
- `context['application']`: The application the user is in the process of authorizing. (Optional)
|
||||
- `context['source']`: The source the user is authenticating/enrolling with. (Optional)
|
||||
- `context['pending_user']`: The currently pending user, see [User](../../users-sources/user/user_ref.md)
|
||||
- `context['pending_user']`: The currently pending user, see [User](../../users-sources/user/user_ref.mdx)
|
||||
- `context['is_restored']`: Contains the flow token when the flow plan was restored from a link, for example the user clicked a link to a flow which was sent by an email stage. (Optional)
|
||||
- `context['auth_method']`: Authentication method (this value is set by password stages) (Optional)
|
||||
|
||||
|
@ -2,7 +2,7 @@
|
||||
title: Managing flow context keys
|
||||
---
|
||||
|
||||
[Flow context](../../../add-secure-apps/flows-stages/flow/context/index.md) can be managed in [Expression policies](../expression.mdx) via the `context['flow_plan'].context` variable.
|
||||
[Flow context](../../../add-secure-apps/flows-stages/flow/context/index.mdx) can be managed in [Expression policies](../expression.mdx) via the `context['flow_plan'].context` variable.
|
||||
|
||||
Here's an example of setting a key in an Expression policy:
|
||||
|
||||
|
@ -8,7 +8,7 @@ authentik provides several [standard policy types](./index.md#standard-policies)
|
||||
|
||||
We also document how to use a policy to [whitelist email domains](./expression/whitelist_email.md) and to [ensure unique email addresses](./expression/unique_email.md).
|
||||
|
||||
To learn more see also [bindings](../../add-secure-apps/flows-stages/bindings/index.md) and how to use the [authentik Wizard to bind policy bindings to the new application](../../add-secure-apps/applications/manage_apps.md#add-new-applications) (for example, to configure application-specific access).
|
||||
To learn more see also [bindings](../../add-secure-apps/flows-stages/bindings/index.md) and how to use the [authentik Wizard to bind policy bindings to the new application](../../add-secure-apps/applications/manage_apps.mdx#add-new-applications) (for example, to configure application-specific access).
|
||||
|
||||
## Create a policy
|
||||
|
||||
|
Reference in New Issue
Block a user