style: format docs

docs/docs/admin/managing-users-identities.mdx

@@ -6,29 +6,35 @@ title: Managing Users and Identities
 import Tabs from '@theme/Tabs'
 import TabItem from '@theme/TabItem'
 
-This document walks you through the administrative identity management in ORY Kratos. You should already
-be familiar with the [Identity Data Model](../concepts/identity-data-model) before reading this guide.
+This document walks you through the administrative identity management in ORY
+Kratos. You should already be familiar with the
+[Identity Data Model](../concepts/identity-data-model) before reading this
+guide.
 
 ## Creating an Identity
 
-There are three principal flows supported for creating identities as an administrator:
+There are three principal flows supported for creating identities as an
+administrator:
 
 1. Inviting users - e.g. inviting a new employee to your organization IT.
-2. Importing existing users - e.g. when migrating from another system to ORY Kratos.
+2. Importing existing users - e.g. when migrating from another system to ORY
+   Kratos.
 3. Creating machine users - e.g. creating Service Accounts.
 
 :::note
 
-Similar to other guides, we assume that ORY Kratos runs on 127.0.0.1:4433 (public endpoint) and
-127.0.0.1:4434 (admin endpoint) in this guide, which is the default when running the quickstart.
+Similar to other guides, we assume that ORY Kratos runs on 127.0.0.1:4433
+(public endpoint) and 127.0.0.1:4434 (admin endpoint) in this guide, which is
+the default when running the quickstart.
 
 :::
 
 ### Invite a User
 
-The goal of this flow is to create an identity and provide the end-user with a way
-of signing into the identity (account) and setting their password (or any other type of credential)
-for future logins. To achieve this, first create the identity and set its traits and schema:
+The goal of this flow is to create an identity and provide the end-user with a
+way of signing into the identity (account) and setting their password (or any
+other type of credential) for future logins. To achieve this, first create the
+identity and set its traits and schema:
 
 ```shell script
 $ curl --request POST -sL \
@@ -51,10 +57,12 @@ $ curl --request POST -sL \
 }
 ```
 
-Keep in mind that you can change the `schema_id` to reflect the schema you want to use for this user. Similarly,
-the trait key/values depend on your schema as well. The command shown does not create a password for the identity
-or any other type of credential. Instead, we will use another REST call to create a recovery link (here "invite link" is
-probably more appropriate, but the flow uses an account recovery link).
+Keep in mind that you can change the `schema_id` to reflect the schema you want
+to use for this user. Similarly, the trait key/values depend on your schema as
+well. The command shown does not create a password for the identity or any other
+type of credential. Instead, we will use another REST call to create a recovery
+link (here "invite link" is probably more appropriate, but the flow uses an
+account recovery link).
 
 To create the account recovery link, use:
 
@@ -113,9 +121,10 @@ func main() {
 }
 ```
 
-The response contains a `recovery_link` value which is the link the user should use to set up his or her credentials
-(e.g. connect to a Social Sign In Provider, set up a password, ...). The user has only a limited amount of time to do
-so - the amount of time is specified in the ORY Kratos config:
+The response contains a `recovery_link` value which is the link the user should
+use to set up his or her credentials (e.g. connect to a Social Sign In Provider,
+set up a password, ...). The user has only a limited amount of time to do so -
+the amount of time is specified in the ORY Kratos config:
 
 ```yaml title="path/to/kratos/config.yml"
 selfservice:
@@ -124,10 +133,11 @@ selfservice:
       privileged_session_max_age: 30m
 ```
 
-If the user fails to set up his / her credentials in time, another recovery link needs to be issued and the user
-needs to re-do the flow.
+If the user fails to set up his / her credentials in time, another recovery link
+needs to be issued and the user needs to re-do the flow.
 
-It is currently not possible to send the recovery link directly to a user's email, this feature is tracked as
+It is currently not possible to send the recovery link directly to a user's
+email, this feature is tracked as
 [#595](https://github.com/ory/kratos/issues/595).
 
 </TabItem>

docs/docs/concepts/identity-data-model.md

@@ -11,11 +11,10 @@ programmatic identity such as an IoT device, application, or some other type of
 :::info
 
 In ORY Kratos' terminology we call all of them "identities", and it is always
-exposed as `identity` in the API endpoints, requests, and response payloads.
-In the documentation however, we mix these words as "account recovery" or "account activation"
-is a widely accepted and understood terminology and user flow,
-while "identity recovery" or "identity activation" is not.
-:::
+exposed as `identity` in the API endpoints, requests, and response payloads. In
+the documentation however, we mix these words as "account recovery" or "account
+activation" is a widely accepted and understood terminology and user flow, while
+"identity recovery" or "identity activation" is not. :::
 
 The following examples use YAML for improved readability. However, the API
 payload is usually in JSON format. An `identity` has the following properties:
@@ -70,20 +69,16 @@ Identities are
 
 - `created` - via API or self-service registration);
 - `updated` - via API or self-serfice settings, account recovery, ...;
-- `disabled` - not yet implemented, see [#598](https://github.com/ory/kratos/issues/598);
-- `deleted` - via API or with a self-service flow (not yet implemented see [#596](https://github.com/ory/kratos/issues/596)).
+- `disabled` - not yet implemented, see
+  [#598](https://github.com/ory/kratos/issues/598);
+- `deleted` - via API or with a self-service flow (not yet implemented see
+  [#596](https://github.com/ory/kratos/issues/596)).
 
-The identity state is therefore `active` or `disabled` (not yet implemented see [#598](https://github.com/ory/kratos/issues/598):
+The identity state is therefore `active` or `disabled` (not yet implemented see
+[#598](https://github.com/ory/kratos/issues/598):
 
 <Mermaid
-  chart={`
-stateDiagram-v2
-	[*] --> Active: create
-    Active --> Active: update
-	Active --> Disabled: disable
-	Disabled --> [*]: delete
-    Disabled --> Active: enable
-`}
+chart={`stateDiagram-v2 [*] --> Active: create Active --> Active: update Active --> Disabled: disable Disabled --> [*]: delete Disabled --> Active: enable`}
 />
 
 ## Identity Traits and JSON Schemas

docs/docs/concepts/terminology.mdx

@@ -3,24 +3,25 @@ id: terminology
 title: Terminology
 ---
 
-The purpose of this document is to define terminology used through this documentation.
+The purpose of this document is to define terminology used through this
+documentation.
 
 ## End-User
 
 The person who actually uses a particular product that uses ORY Kratos.
 
 ## Identity
 
-the "who" of a software system. It can be a customer, employee, user, contractor, or even a
-programmatic identity such as an IoT device, application, or some other type of
-"robot."
+the "who" of a software system. It can be a customer, employee, user,
+contractor, or even a programmatic identity such as an IoT device, application,
+or some other type of "robot."
 
 Common aliases are "user", "user account", "account", "subject".
 
 ## Self-Service
 
-Interfaces and flows allowing customers to produce services
-independent of involvement of direct service employee.
+Interfaces and flows allowing customers to produce services independent of
+involvement of direct service employee.
 
-You perform self-service registration when signing up for a new Goole account, because no one (e.g. support)
-else is involved in the process.
+You perform self-service registration when signing up for a new Goole account,
+because no one (e.g. support) else is involved in the process.

docs/docs/guides/configuring-cookies.mdx

@@ -5,39 +5,46 @@ title: Configuring Cookies
 
 When working with cookies, keep the following in mind:
 
-1. HTTP Cookies **are not port specific**. If a cookie is set on `https://mydomain.com:1234` it is also valid for
-`https://mydomain.com:4321` and `https://mydomain.com`.
+1. HTTP Cookies **are not port specific**. If a cookie is set on
+   `https://mydomain.com:1234` it is also valid for `https://mydomain.com:4321`
+   and `https://mydomain.com`.
 2. Unless `--dev` is set, ORY Kratos' cookies are only sent over HTTPS.
 3. Cookies in ORY Kratos are always `httpOnly`.
-4. It is possible to set a cookie for `mydomain.com` when the original request was made to `subdomain.mydomain.com`.
-It is however not possible to set a cookie for `anotherdomain.com` when the original request was made to `mydomain.com`.
-See also [this answer] on [SackOverflow](https://stackoverflow.com/questions/18492576/share-cookie-between-subdomain-and-domain).
+4. It is possible to set a cookie for `mydomain.com` when the original request
+   was made to `subdomain.mydomain.com`. It is however not possible to set a
+   cookie for `anotherdomain.com` when the original request was made to
+   `mydomain.com`. See also [this answer] on
+   [SackOverflow](https://stackoverflow.com/questions/18492576/share-cookie-between-subdomain-and-domain).
 
 :::note
 
-ORY Kratos uses pass-by-value cookies whose values are encrypted using the `secrets.default` / `secrets.cookie` secrets.
-If these secrets are changed without doing proper [secret / key rotation](secret-key-rotation), all cookies will be invalid
-which will cause users to be signed out, and other side effects.
+ORY Kratos uses pass-by-value cookies whose values are encrypted using the
+`secrets.default` / `secrets.cookie` secrets. If these secrets are changed
+without doing proper [secret / key rotation](secret-key-rotation), all cookies
+will be invalid which will cause users to be signed out, and other side effects.
 
 :::
 
 ## Session Cookies
 
-CloudRun, Heroku, and other "serverless" solutions commonly expose services directly to the public,
-and do not allow for fronting by a gateway or reverse proxy. In those cases, your application architecture
-may separate services by subdomain (e.g. `service1.myproduct.com`, `service2.myproduct.com`,
+CloudRun, Heroku, and other "serverless" solutions commonly expose services
+directly to the public, and do not allow for fronting by a gateway or reverse
+proxy. In those cases, your application architecture may separate services by
+subdomain (e.g. `service1.myproduct.com`, `service2.myproduct.com`,
 `service3.myproduct.com`, ...).
 
-If that is the case you can change the session [cookie domain](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies)
-and path using the following configuration keys in your ORY Kratos configuration:
+If that is the case you can change the session
+[cookie domain](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies) and
+path using the following configuration keys in your ORY Kratos configuration:
 
 ```yaml title="path/to/kratos/config.yml
 session:
   cookie:
     domain: myproduct.com
 ```
 
-It is also possible to restrict the [cookie path](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies):
+It is also possible to restrict the
+[cookie path](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies):
 
 :::note
 
@@ -51,7 +58,8 @@ session:
     path: /some/sub-directory
 ```
 
-You can also modify the new [HTTP Cookie SameSite Attribute](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite)
+You can also modify the new
+[HTTP Cookie SameSite Attribute](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite)
 using:
 
 ```yaml title="path/to/kratos/config.yml

docs/docs/guides/docker.md

@@ -4,43 +4,68 @@ title: Docker Images
 ---
 
 ## Supported tags and respective `Dockerfile` links
-* [`latest`, `v0.4.3-alpha.1`, `v0.4.3`, `v0.4`, `v0`](https://github.com/ory/kratos/blob/v0.4.3-alpha.1/.docker/Dockerfile)
-* [`latest-sqlite`, `v0.4.3-alpha.1-sqlite`, `v0.4.3-sqlite`, `v0.4-sqlite`, `v0-sqlite`](https://github.com/ory/kratos/blob/v0.4.3-alpha.1/.docker/Dockerfile-sqlite)
+
+- [`latest`, `v0.4.3-alpha.1`, `v0.4.3`, `v0.4`, `v0`](https://github.com/ory/kratos/blob/v0.4.3-alpha.1/.docker/Dockerfile)
+- [`latest-sqlite`, `v0.4.3-alpha.1-sqlite`, `v0.4.3-sqlite`, `v0.4-sqlite`, `v0-sqlite`](https://github.com/ory/kratos/blob/v0.4.3-alpha.1/.docker/Dockerfile-sqlite)
 
 ## Image Variants
-The `Kratos` Docker images come in two different falvors, one with and one without SQLite support. All Docker images with the postfix `kratos:<version>-sqlite` in the tag are compiled with embed SQLite support and uses libmusl. All Docker images (`kratos:<version>`) without the postfix `-sqlite` are compiled without SQLite support and therefore also don't include libmusl. 
 
-If you don't make use of the embedded SQLite support we recommend to use the Docker images without SQLite support as they are smaller in size, include fewer libraries and therefore have a smaller attack surface. 
+The `Kratos` Docker images come in two different falvors, one with and one
+without SQLite support. All Docker images with the postfix
+`kratos:<version>-sqlite` in the tag are compiled with embed SQLite support and
+uses libmusl. All Docker images (`kratos:<version>`) without the postfix
+`-sqlite` are compiled without SQLite support and therefore also don't include
+libmusl.
+
+If you don't make use of the embedded SQLite support we recommend to use the
+Docker images without SQLite support as they are smaller in size, include fewer
+libraries and therefore have a smaller attack surface.
 
 ## How to use these images
-In order to make the provided Docker images as useful as possible they can be configured through a set of supported Environment variables. In addition the default configuration directoy can be bound to a directory of choice to make it simple to pass in your own configuration files.
+
+In order to make the provided Docker images as useful as possible they can be
+configured through a set of supported Environment variables. In addition the
+default configuration directoy can be bound to a directory of choice to make it
+simple to pass in your own configuration files.
 
 ### Environment Variables
+
 #### `DSN`
-This environment variable allows you to specify the database source name. As the `DSN` normally consists of the url to the database system and the credentials to access the database it is recommended to specify the `DSN` using a Environment variable. 
 
-**Example:** 
+This environment variable allows you to specify the database source name. As the
+`DSN` normally consists of the url to the database system and the credentials to
+access the database it is recommended to specify the `DSN` using a Environment
+variable.
 
-`docker run -e DSN="memory" oryd/kratos:latest`
+**Example:**
 
+`docker run -e DSN="memory" oryd/kratos:latest`
 
 #### `SECRETS_DEFAULT`
-This environment variable allows you to specify the secret used to sign and verify signatures and encrypt things:
 
-**Example:** 
+This environment variable allows you to specify the secret used to sign and
+verify signatures and encrypt things:
 
-`docker run -e SECRETS_DEFAULT="CHANGE-ME" oryd/kratos:v0.4.3-alpha.1`
+**Example:**
 
+`docker run -e SECRETS_DEFAULT="CHANGE-ME" oryd/kratos:v0.4.3-alpha.1`
 
 ### Volumes
-If the file `$HOME/.kratos.yaml` exists, it will be used as the configuration file. The provided Kratos Docker images currently do not include a default configuration file, but make it easy to pass in your own configuration file(s) by either binding a local directory or by creating your own custom Docker Image and adding the configuration file(s) to the custom image. 
+
+If the file `$HOME/.kratos.yaml` exists, it will be used as the configuration
+file. The provided Kratos Docker images currently do not include a default
+configuration file, but make it easy to pass in your own configuration file(s)
+by either binding a local directory or by creating your own custom Docker Image
+and adding the configuration file(s) to the custom image.
 
 #### Binding host directoy
 
-**Example:**
-In this example we start the standard Docker container with SQLite support and use the quickstart email-passwort example configuration files by bind mounting the local directory. This example assumes that you checked out the Kratos Git repo and execute the Docker command in the Kratos Git repo directory:
+**Example:** In this example we start the standard Docker container with SQLite
+support and use the quickstart email-passwort example configuration files by
+bind mounting the local directory. This example assumes that you checked out the
+Kratos Git repo and execute the Docker command in the Kratos Git repo directory:
 
-``` 
+```
 docker run -it -e DSN="memory" \
        --mount type=bind,source="$(pwd)"/contrib/quickstart/kratos/email-password,target=/home/ory \
        oryd/kratos:latest-sqlite
@@ -49,13 +74,17 @@ docker run -it -e DSN="memory" \
 In general we only recommend this approach for local development.
 
 #### Creating custom Docker image
-You can create your own, custom Kratos Docker images which embeds your configuration files by simply using the official Kratos Docker images as the Base Image and just adding your configuration file(s) as shown in the example below:
 
-``` dockerfile
+You can create your own, custom Kratos Docker images which embeds your
+configuration files by simply using the official Kratos Docker images as the
+Base Image and just adding your configuration file(s) as shown in the example
+below:
+
+```dockerfile
 FROM oryd/kratos:latest
 COPY contrib/quickstart/kratos/email-password/.kratos.yml /ory/home
 ```
 
-
 ### Examples
+
 Below you find different examples how to use the official Kratos Docker images.

docs/docs/guides/login-session.mdx

@@ -3,16 +3,17 @@ id: login-session
 title: Login Sessions
 ---
 
-A login session is created when a user signs in. The session is stored as a cookie or as a token, depending
-on the interaction type. A session is valid for the session lifespan you specify in the ORY Kratos config:
+A login session is created when a user signs in. The session is stored as a
+cookie or as a token, depending on the interaction type. A session is valid for
+the session lifespan you specify in the ORY Kratos config:
 
 ```yaml title="path/to/kratos/config.yml
 session:
   lifespan: 720h # 30 days
 ```
 
-Per default the session cookie has the `max-age` parameter set to the specified session lifespan.
-You may disable this behavior by setting:
+Per default the session cookie has the `max-age` parameter set to the specified
+session lifespan. You may disable this behavior by setting:
 
 ```yaml title="path/to/kratos/config.yml
 session:
@@ -25,8 +26,8 @@ session:
 The cookie `max-age` parameter behaves as follows:
 
 - The browser interprets the cookie to be removed when the session ends if
-`max-age` is not set as part of the `Set-Cookie` header. A session ends if the browser is terminated due to
-a reboot or when shutting down the browser.
+  `max-age` is not set as part of the `Set-Cookie` header. A session ends if the
+  browser is terminated due to a reboot or when shutting down the browser.
 - The browser keeps the cookie until `max-age` is reached otherwise.
 
 :::