yes

docs/reference/configuration.md

@@ -5,7 +5,7 @@ description: Documentation how Bifröst can be configured will all its possible
 
 Bifröst will be configured in the [YAML language](https://en.wikipedia.org/wiki/YAML).
 
-By default, the configuration is token from the following location:
+By default, the configuration is taken from the following location:
 
 * Linux: `/etc/engity/bifroest/configuration.yaml`
 * Windows: `C:\ProgramData\Engity\Bifroest\configuration.yaml`

docs/reference/environment/index.md

@@ -1,10 +1,10 @@
 ---
-description: How environments within Bifröst work where the users sessions are executed.
+description: How environments within Bifröst work when user sessions are executed.
 ---
 
 # Environments
 
-Bifröst executes user sessions within environments. These environments can either be the [local environment](local.md) of the host (where Bifröst runs on) itself or even containers (currently in development [Docker](https://github.com/engity-com/bifroest/issues/11) and [Kubernetes](https://github.com/engity-com/bifroest/issues/12)).
+Bifröst executes user sessions within environments. These environments can either be the [local environment](local.md) of the host (on which Bifröst runs on) itself or even containers (currently in development [Docker](https://github.com/engity-com/bifroest/issues/11) and [Kubernetes](https://github.com/engity-com/bifroest/issues/12)).
 
 ## Types
 

docs/reference/environment/local.md

@@ -1,11 +1,11 @@
 ---
-description: A Local environment is executed on the host itself (same host where Bifröst is running).
+description: A Local environment is executed on the host itself (same host on which Bifröst is running).
 toc_depth: 4
 ---
 
 # Local environment
 
-A local environment is executed on the host itself (same host where Bifröst is running).
+A local environment is executed on the host itself (same host on which Bifröst is running).
 
 Currently, we support different variants provided by the host operating system which is executing the environment.
 
@@ -78,7 +78,7 @@ The display name (or _title_ or [_GECOS_](https://en.wikipedia.org/wiki/Gecos_fi
 
 ##### Examples {: #linux-property-name-examples}
 1. In case of [local user](../authorization/local.md) should be never be defined.
-2. Use the email address of [the user authorized via OIDC](../authorization/oidc.md):
+2. Use the e-mail address of [the user authorized via OIDC](../authorization/oidc.md):
    ```yaml
    displayName: "{{.authorization.idToken.name}}"
    ```
@@ -124,7 +124,7 @@ The groups (do not confuse with the [primary group](#linux-property-group)) the
    ```
 
 <<property_with_holder("shell", "String Template", "../templating/index.md#string", "Authorization", "../context/authorization.md", default="/bin/sh", id_prefix="linux-", heading=4, requirement="linux-user-requirement")>>
-The [shell](https://en.wikipedia.org/wiki/Shell_(computing)) the user should have. Not defined means this requirement won'T be evaluated or applied (in case of creation/modification of a user).
+The [shell](https://en.wikipedia.org/wiki/Shell_(computing)) the user should have. Not defined means this requirement won't be evaluated or applied (in case of creation/modification of a user).
 
 <<property_with_holder("homeDir", "String Template", "../templating/index.md#string", "Authorization", "../context/authorization.md", default="/home/<user.name>", id_prefix="linux-", heading=4, requirement="linux-user-requirement")>>
 The home directory the user should have. Not defined means this requirement won't be evaluated or applied (in case of creation/modification of a user).
@@ -135,7 +135,7 @@ If a new user needs to be created in a directory on the Bifröst hosts, it will
 <<property_with_holder("createIfAbsent", "Bool Template", "../templating/index.md#bool", "Authorization", "../context/authorization.md", default=false, id_prefix="linux-", heading=4)>>
 Will create the local user if it does not exist to match the provided requirements (see below). If this property is `false` the user has to exist, otherwise the execution will fail and the connection will be closed immediately.
 
-This property (together with [`updateIfDifferent`](#linux-property-updateIfDifferent)) should be `true` if you're using authorizations like [OIDC](../authorization/oidc.md), where the user is not expected to exist locally, and you don't want to create each user individually.
+This property (together with [`updateIfDifferent`](#linux-property-updateIfDifferent)) has to be `true` if you're using authorizations like [OIDC](../authorization/oidc.md), where the user is not expected to exist locally, and you don't want to create each user individually.
 
 ##### Evaluation {: #linux-property-createIfAbsent-evaluation}
 | [`createIfAbsent`](#linux-property-createIfAbsent) | = `false`  | = `true` |
@@ -145,15 +145,15 @@ This property (together with [`updateIfDifferent`](#linux-property-updateIfDiffe
 | Does not exist | :octicons-x-circle-24: Rejected | :octicons-check-circle-24: Created and accepted |
 
 <<property_with_holder("updateIfDifferent", "Bool Template", "../templating/index.md#bool", "Authorization", "../context/authorization.md", default=false, id_prefix="linux-", heading=4)>>
-If an existing user does not match the provided requirements (see below) and this property is `true`, this user will be adjusted to match the requirements.
+If an existing user does not match the provided requirements (see below) and the property is `true`, this user is asked to match the requirements.
 
 This property (together with [`createIfAbsent`](#linux-property-createIfAbsent)) should be `true` if you're using authorizations like [OIDC](../authorization/oidc.md), where the user is not expected to exist locally and you don't want to create each user individually.
 
 ##### Evaluation {: #linux-property-updateIfDifferent-evaluation}
 | [`updateIfDifferent`](#linux-property-updateIfDifferent) | = `false`  | = `true` |
 | - | - | - |
 | Exists and matches | :octicons-check-circle-24: Accepted | :octicons-check-circle-24: Accepted |
-| Exists, but does not match | :octicons-x-circle-24: Rejected | :octicons-check-circle-24: Modified and accepted |
+| Exists but does not match | :octicons-x-circle-24: Rejected | :octicons-check-circle-24: Modified and accepted |
 | Does not exist | _Does not apply_ | _Does not apply_ |
 
 <<property_with_holder("banner", "String Template", "../templating/index.md#string", "Authorization", "../context/authorization.md", default="", id_prefix="linux-", heading=4)>>
@@ -173,7 +173,7 @@ Will be displayed to the user upon connection to its environment.
 If `true`, users are allowed to use SSH's port forwarding mechanism.
 
 <<property("dispose", "Dispose", "#linux-dispose", id_prefix="linux-", heading=4)>>
-Defines what should happen if an environment will be disposed.
+Defines what happens if an environment is disposed.
 
 ### Examples {: #linux-examples}
 
@@ -292,7 +292,7 @@ The executor command prefix which is used when a user executes a command instead
 If the user will execute `ssh foo@bar.com echo "bar"` on the host `C:\WINDOWS\system32\cmd.exe /C 'echo "bar"'` will be executed.
 
 <<property_with_holder("directory", "Strings Template", "../templating/index.md#string", "Authorization", "../context/authorization.md", "<working directory of Bifröst>", id_prefix="windows-", heading=4)>>
-The working directory where the command will be executed in.
+The working directory in which the command will be executed in.
 
 <<property_with_holder("portForwardingAllowed", "Bool Template", "../templating/index.md#bool", "Authorization", "../context/authorization.md", True, id_prefix="windows-", heading=4)>>
 If `true`, users are allowed to use SSH's port forwarding mechanism.

docs/reference/flow.md

@@ -6,7 +6,7 @@ description: A flow represents a flow of a user's session from the authorization
 
 A flow represents a flow of a user's session from the [authorization](authorization/index.md) to the active [environment](environment/index.md). Unlike the majority of the SSH servers, Bifröst cannot only interpret one flow, it can interpret *one or more*. With this approach Bifröst can do something similar like HTTP servers are implementing [Virtual hosting](https://en.wikipedia.org/wiki/Virtual_hosting) - but in this case it is based on the combination of the requesting usernames (see [requirement](#requirement)) and which [authorization](authorization/index.md) the user can fulfill.
 
-For each configured flow, Bifröst will evaluate the following checks. If one of them does not succeed, Bifröst will end the evaluating of the current flow and will try the next one as long more candidates are available:
+For each configured flow, Bifröst will evaluate the following checks. If one of them does not succeed, Bifröst will end the evaluating of the current flow and will try the next one as long as more candidates are available:
 
 1. Is there already a matching [session](session/index.md) existing; if yes: Execute immediately into the environment of this [session](session/index.md) and skip the following evaluations.
 2. Is the [requirement](#requirement) fulfilled?
@@ -29,7 +29,7 @@ For each configured flow, Bifröst will evaluate the following checks. If one of
 :   Will be evaluated to ensure the requesting user is allowed to access [the environment of this flow](#property-environment).
 
 <<property("environment", "Environment", "environment/index.md", required=True)>>
-:   Once all requirements are fulfilled and the user is authorized successfully, he will execute into this [environment](environment/index.md).
+:   Once all requirements are fulfilled and the user is successfully authorized, he will execute into this [environment](environment/index.md).
 
 ## Example
 

docs/setup/index.md

@@ -47,7 +47,7 @@ toc_depth: 2
 
 ### systemd
 
-To enable Bifröst to run on every server start where [systemd](https://wiki.archlinux.org/title/Systemd) is available, simply:
+To enable Bifröst to run on every server, start where [systemd](https://wiki.archlinux.org/title/Systemd) is available, simply:
 1. Download <<asset_link("contrib/systemd/bifroest.service", "our example service configuration")>>:
    ```shell
    sudo curl -sSLf <<asset_url("contrib/systemd/bifroest.service", True)>> -o /etc/systemd/system/bifroest.service