Check max line width to 120 chars in prettier

CONTRIBUTING.md

@@ -17,14 +17,14 @@ We welcome suggestions for improvements. To propose an enhancement, [open a new
 1. **Fork the Repository**: Click the "Fork" button at the top right of the repository page.
 
 2. **Clone Your Fork**:
-   ```bash
+   ```shell
    git clone https://github.com/opencloud-eu/docs.git
    cd docs
    ```
 
 3. **Create a New Branch**:
 
-    ```bash
+    ```shell
     git checkout -b feature/your-feature-name
     ```
 
@@ -34,13 +34,13 @@ Implement your changes, adhering to the docs style.
 
 5. **Commit Your Changes**:
 
-    ```bash
+    ```shell
     git commit -m "Brief description of your changes"
     ```
 
 6. **Push to Your Fork**:
 
-    ```bash
+    ```shell
     git push origin feature/your-feature-name
     ```
 

README.md

@@ -4,15 +4,15 @@ This website is built using [Docusaurus](https://docusaurus.io/), a modern stati
 
 ### Installation
 
-```bash
+```shell
 pnpm install
 ```
 
 ### Local Development
 
 clone this repository
 
-```bash
+```shell
 pnpm start
 ```
 
@@ -22,15 +22,15 @@ This command starts a local development server and opens up a browser window. Mo
 
 To see the docs in German you need to start it with the following command
 
-```bash
+```shell
 pnpm run start --locale de
 ```
 
 It is not possible to switch between the languages via the language switcher
 
 ### Build
 
-```bash
+```shell
 pnpm build
 ```
 
@@ -40,13 +40,13 @@ This command generates static content into the `build` directory and can be serv
 
 Using SSH:
 
-```bash
+```shell
 USE_SSH=true pnpm deploy
 ```
 
 Not using SSH:
 
-```bash
+```shell
 GIT_USER=<Your GitHub username> pnpm deploy
 ```
 

assets/likec4/README.md

@@ -31,7 +31,7 @@ These are automatically generated during the build process and updated with each
 
 The project has a built-in script to render the C4 models:
 
-```bash
+```shell
 # Install dependencies
 pnpm install
 

docs/admin/configuration/authentication-and-user-management/external-idp.md

@@ -12,51 +12,37 @@ The following environment variables are relevant when connecting OpenCloud to an
 
 - `OC_OIDC_ISSUER`: Set this to the issuer URL of the external Identity Provider
 - `OC_EXCLUDE_RUN_SERVICES`: To disable the built-in Identity Provider set this to `idp`
-- `PROXY_OIDC_REWRITE_WELLKNOWN`: Set this to `true` to expose the Identity
-  Providers `.well-known/openid-configuration` via the OpenCloud base url. This
-  help the oidc client, that do not yet support discovery via webfinger to
-  locate the Identity Provider's configuration.
-- `PROXY_USER_OIDC_CLAIM` and `PROXY_USER_CS3_CLAIM`: These two variables
-  configure how the users mapped between the Identity Provider and OpenCloud.
-  `PROXY_USER_OIDC_CLAIM` defines the OIDC claim that OpenCloud uses to
-  uniquely identify a user. It is matched against the OpenCloud user attribute
-  defined in `PROXY_USER_CS3_CLAIM`. E.g. if `PROXY_USER_OIDC_CLAIM` is set to
-  `preferred_username` and `PROXY_USER_CS3_CLAIM` is set to `username` then an
-  OpenID Connect user, that has the `preferred_username` set to `alan` will map
-  to the OpenCloud user with username `alan`.
-- `PROXY_AUTOPROVISION_ACCOUNTS` and `GRAPH_USERNAME_MATCH`: When
-  `PROXY_AUTOPROVISION_ACCOUNTS` is set to `true`, OpenCloud will create a new
-  user account in the LDAP Database for every user who logs in via OpenID
-  Connect for the first time. Enabling this requires access to a writable LDAP
-  server. For smaller setups this can be the built-in LDAP server provided by
-  the `idm` service. If set to `false` all users logging in must already be
-  existing in the LDAP server. (The mapping between the OIDC and LDAP users
-  happens based on the aforementioned `PROXY_USER_OIDC_CLAIM` and
-  `PROXY_USER_CS3_CLAIM` settings. Set `GRAPH_USERNAME_MATCH` to `none` when
-  `PROXY_AUTOPROVISION_ACCOUNTS` is set to `true` to disable OpenCloud's
-  default restrictions on allowed characters in usernames.
-- `PROXY_ROLE_ASSIGNMENT_DRIVER` and `GRAPH_ASSIGN_DEFAULT_USER_ROLE`: For
-  details see below
+- `PROXY_OIDC_REWRITE_WELLKNOWN`: Set this to `true` to expose the Identity Providers `.well-known/openid-configuration`
+  via the OpenCloud base url. This help the oidc client, that do not yet support discovery via webfinger to locate the
+  Identity Provider's configuration.
+- `PROXY_USER_OIDC_CLAIM` and `PROXY_USER_CS3_CLAIM`: These two variables configure how the users mapped between the
+  Identity Provider and OpenCloud. `PROXY_USER_OIDC_CLAIM` defines the OIDC claim that OpenCloud uses to uniquely
+  identify a user. It is matched against the OpenCloud user attribute defined in `PROXY_USER_CS3_CLAIM`. E.g. if
+  `PROXY_USER_OIDC_CLAIM` is set to `preferred_username` and `PROXY_USER_CS3_CLAIM` is set to `username` then an OpenID
+  Connect user, that has the `preferred_username` set to `alan` will map to the OpenCloud user with username `alan`.
+- `PROXY_AUTOPROVISION_ACCOUNTS` and `GRAPH_USERNAME_MATCH`: When `PROXY_AUTOPROVISION_ACCOUNTS` is set to `true`,
+  OpenCloud will create a new user account in the LDAP Database for every user who logs in via OpenID Connect for the
+  first time. Enabling this requires access to a writable LDAP server. For smaller setups this can be the built-in LDAP
+  server provided by the `idm` service. If set to `false` all users logging in must already be existing in the LDAP
+  server. (The mapping between the OIDC and LDAP users happens based on the aforementioned `PROXY_USER_OIDC_CLAIM` and
+  `PROXY_USER_CS3_CLAIM` settings. Set `GRAPH_USERNAME_MATCH` to `none` when `PROXY_AUTOPROVISION_ACCOUNTS` is set to
+  `true` to disable OpenCloud's default restrictions on allowed characters in usernames.
+- `PROXY_ROLE_ASSIGNMENT_DRIVER` and `GRAPH_ASSIGN_DEFAULT_USER_ROLE`: For details see below
 
 ### Automatic Role Assignments
 
-When users login into OpenCloud, they get a user role assigned
-automatically. The automatic role assignment can be configured in different
-ways. The `PROXY_ROLE_ASSIGNMENT_DRIVER` environment variable (or the `driver`
-setting in the `role_assignment` section of the configuration file) select which
-mechanism to use for the automatic role assignment.
+When users login into OpenCloud, they get a user role assigned automatically. The automatic role assignment can be
+configured in different ways. The `PROXY_ROLE_ASSIGNMENT_DRIVER` environment variable (or the `driver` setting in the
+`role_assignment` section of the configuration file) select which mechanism to use for the automatic role assignment.
 
-When set to `default`, all users which do not have a role assigned at the time
-of first login will get the role 'user' assigned. This is also the
-default behavior if `PROXY_ROLE_ASSIGNMENT_DRIVER` is unset.
+When set to `default`, all users which do not have a role assigned at the time of first login will get the role 'user'
+assigned. This is also the default behavior if `PROXY_ROLE_ASSIGNMENT_DRIVER` is unset.
 
-When `PROXY_ROLE_ASSIGNMENT_DRIVER` is set to `oidc` the role assignment for a
-user will happen based on the values of an OpenID Connect Claim of that user.
-The name of the OpenID Connect Claim to be used for the role assignment can be
-configured via the `PROXY_ROLE_ASSIGNMENT_OIDC_CLAIM` environment variable. It
-is also possible to define a mapping of claim values to role names defined in
-OpenCloud via a `yaml` configuration. See the following `proxy.yaml` snippet
-for an example.
+When `PROXY_ROLE_ASSIGNMENT_DRIVER` is set to `oidc` the role assignment for a user will happen based on the values of
+an OpenID Connect Claim of that user. The name of the OpenID Connect Claim to be used for the role assignment can be
+configured via the `PROXY_ROLE_ASSIGNMENT_OIDC_CLAIM` environment variable. It is also possible to define a mapping of
+claim values to role names defined in OpenCloud via a `yaml` configuration. See the following `proxy.yaml` snippet for
+an example.
 
 ```yaml
 role_assignment:
@@ -74,21 +60,20 @@ role_assignment:
         claim_value: myGuestRole
 ```
 
-This would assign the role `admin` to users with the value `myAdminRole` in the claim `opencloudRoles`.
-The role `user` to users with the values `myUserRole` in the claims `opencloudRoles` and so on.
+This would assign the role `admin` to users with the value `myAdminRole` in the claim `opencloudRoles`. The role `user`
+to users with the values `myUserRole` in the claims `opencloudRoles` and so on.
 
 Claim values that are not mapped to a specific OpenCloud role will be ignored.
 
-Note: An OpenCloud user can only have a single role assigned. If the configured
-`role_mapping` and a user's claim values result in multiple possible roles for a user, the order in
-which the role mappings are defined in the configuration is important. The first role in the
-`role_mappings` where the `claim_value` matches a value from the user's roles claim will be assigned
-to the user. So if e.g. a user's `opencloudRoles` claim has the values `myUserRole` and
-`mySpaceAdminRole` that user will get the OpenCloud role `spaceadmin` assigned (because `spaceadmin`
-appears before `user` in the above sample configuration).
+Note: An OpenCloud user can only have a single role assigned. If the configured `role_mapping` and a user's claim values
+result in multiple possible roles for a user, the order in which the role mappings are defined in the configuration is
+important. The first role in the `role_mappings` where the `claim_value` matches a value from the user's roles claim
+will be assigned to the user. So if e.g. a user's `opencloudRoles` claim has the values `myUserRole` and
+`mySpaceAdminRole` that user will get the OpenCloud role `spaceadmin` assigned (because `spaceadmin` appears before
+`user` in the above sample configuration).
 
-If a user's claim values don't match any of the configured role mappings an error will be logged and
-the user will not be able to login.
+If a user's claim values don't match any of the configured role mappings an error will be logged and the user will not
+be able to login.
 
 The default `role_claim` (or `PROXY_ROLE_ASSIGNMENT_OIDC_CLAIM`) is `roles`. The default `role_mapping` is:
 
@@ -103,7 +88,8 @@ The default `role_claim` (or `PROXY_ROLE_ASSIGNMENT_OIDC_CLAIM`) is `roles`. The
   claim_value: opencloudGuest
 ```
 
-Note: When `PROXY_ROLE_ASSIGNMENT_DRIVER` is set to `oidc` it is recommended to set `GRAPH_ASSIGN_DEFAULT_USER_ROLE` to `false`.
+Note: When `PROXY_ROLE_ASSIGNMENT_DRIVER` is set to `oidc` it is recommended to set `GRAPH_ASSIGN_DEFAULT_USER_ROLE` to
+`false`.
 
 ## Client Configuration
 

docs/admin/configuration/authentication-and-user-management/index.md

@@ -18,21 +18,28 @@ OpenCloud employs a dual-track authentication strategy:
 
 ## Authentication with Keycloak
 
-For production environments, we recommend using Keycloak with LDAP integration. This setup provides a robust authentication system that can scale to enterprise needs.
+For production environments, we recommend using Keycloak with LDAP integration. This setup provides a robust
+authentication system that can scale to enterprise needs.
 
 OpenCloud now supports two authentication modes when using Keycloak with LDAP:
 
 ### Shared User Directory Mode
 
-In this mode, LDAP serves as a central user directory for both Keycloak and OpenCloud.
-This setup is suitable for scenarios where the LDAP server is not under the control of the OpenCloud admin and can be connected to KeyCloak and OpenCloud using standard attributes and a read-only bind user.
+In this mode, LDAP serves as a central user directory for both Keycloak and OpenCloud. This setup is suitable for
+scenarios where the LDAP server is not under the control of the OpenCloud admin and can be connected to KeyCloak and
+OpenCloud using standard attributes and a read-only bind user.
 
-For detailed configuration and setup instructions, see the [Keycloak Shared User Directory](./keycloak#shared-user-directory-mode) guide.
+For detailed configuration and setup instructions, see the
+[Keycloak Shared User Directory](./keycloak#shared-user-directory-mode) guide.
 
 ### Autoprovisioning Mode
 
-In this mode, Keycloak is holding all users and OpenCloud autoprovisions new users during first login.
-This mode is suitable in scenarios where the OpenIDConnect provider is external and not under control of the OpenCloud admin. To mitigate that lack of control, OpenCloud will use an LDAP server which is fully under the control of the OpenCloud admin to store the users and groups and additional attributes.
-OpenCloud can disable users for login to actively prevent unwanted access to the system when the workflow with the external Identity Provider is slow or indirect. In this case, the LDAP server needs an OpenCloud Schema and write access for the LDAP bind user.
+In this mode, Keycloak is holding all users and OpenCloud autoprovisions new users during first login. This mode is
+suitable in scenarios where the OpenIDConnect provider is external and not under control of the OpenCloud admin. To
+mitigate that lack of control, OpenCloud will use an LDAP server which is fully under the control of the OpenCloud admin
+to store the users and groups and additional attributes. OpenCloud can disable users for login to actively prevent
+unwanted access to the system when the workflow with the external Identity Provider is slow or indirect. In this case,
+the LDAP server needs an OpenCloud Schema and write access for the LDAP bind user.
 
-For detailed configuration and setup instructions, see the [Keycloak with Autoprovisioning](./keycloak#autoprovisioning-mode) guide.
+For detailed configuration and setup instructions, see the
+[Keycloak with Autoprovisioning](./keycloak#autoprovisioning-mode) guide.