website: Bump prettier from 3.3.3 to 3.4.1 in /website (#12205)

* website: Bump prettier from 3.3.3 to 3.4.1 in /website

Bumps [prettier](https://github.com/prettier/prettier) from 3.3.3 to 3.4.1.
- [Release notes](https://github.com/prettier/prettier/releases)
- [Changelog](https://github.com/prettier/prettier/blob/main/CHANGELOG.md)
- [Commits](https://github.com/prettier/prettier/compare/3.3.3...3.4.1)

---
updated-dependencies:
- dependency-name: prettier
  dependency-type: direct:development
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>

* update formatting

Signed-off-by: Jens Langhammer <jens@goauthentik.io>

* sigh

Signed-off-by: Jens Langhammer <jens@goauthentik.io>

* disable flaky test

Signed-off-by: Jens Langhammer <jens@goauthentik.io>

---------

Signed-off-by: dependabot[bot] <support@github.com>
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Jens Langhammer <jens@goauthentik.io>

website/docs/users-sources/sources/protocols/kerberos/index.md

@@ -13,16 +13,16 @@ This source allows users to enroll themselves with an existing Kerberos identity
 
 The following placeholders will be used:
 
--   `REALM.COMPANY` is the Kerberos realm.
--   `authentik.company` is the FQDN of the authentik install.
+- `REALM.COMPANY` is the Kerberos realm.
+- `authentik.company` is the FQDN of the authentik install.
 
 Examples are shown for an MIT Krb5 KDC system; you might need to adapt them for you Kerberos installation.
 
 There are three ways to use the Kerberos source:
 
--   As a password backend, where users can log in to authentik with their Kerberos password.
--   As a directory source, where users are synced from the KDC.
--   With SPNEGO, where users can log in to authentik with their [browser](./browser.md) and their Kerberos credentials.
+- As a password backend, where users can log in to authentik with their Kerberos password.
+- As a directory source, where users are synced from the KDC.
+- With SPNEGO, where users can log in to authentik with their [browser](./browser.md) and their Kerberos credentials.
 
 You can choose to use one or several of those methods.
 
@@ -30,13 +30,13 @@ You can choose to use one or several of those methods.
 
 In the authentik Admin interface, under **Directory** -> **Federation and Social login**, create a new source of type Kerberos with these settings:
 
--   Name: a value of your choosing. This name is shown to users if you use the SPNEGO login method.
--   Slug: `kerberos`
--   Realm: `REALM.COMPANY`
--   Kerberos 5 configuration: If you need to override the default Kerberos configuration, you can do it here. See [man krb5.conf(5)](https://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_files/krb5_conf.html) for the expected format.
--   User matching mode: define how Kerberos users get matched to authentik users.
--   Group matching mode: define how Kerberos groups (specified via property mappings) get matched to authentik groups.
--   User property mappings and group property mappings: see [Source property mappings](../../property-mappings/index.md) and the section below for details.
+- Name: a value of your choosing. This name is shown to users if you use the SPNEGO login method.
+- Slug: `kerberos`
+- Realm: `REALM.COMPANY`
+- Kerberos 5 configuration: If you need to override the default Kerberos configuration, you can do it here. See [man krb5.conf(5)](https://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_files/krb5_conf.html) for the expected format.
+- User matching mode: define how Kerberos users get matched to authentik users.
+- Group matching mode: define how Kerberos groups (specified via property mappings) get matched to authentik groups.
+- User property mappings and group property mappings: see [Source property mappings](../../property-mappings/index.md) and the section below for details.
 
 ## Password backend
 
@@ -61,9 +61,9 @@ $ rm /tmp/authentik.keytab
 
 In authentik, configure these extra options:
 
--   Sync users: enable it
--   Sync principal: `authentik/admin@REALM.COMPANY`
--   Sync keytab: the base64-encoded keytab created above.
+- Sync users: enable it
+- Sync principal: `authentik/admin@REALM.COMPANY`
+- Sync keytab: the base64-encoded keytab created above.
 
 If you do not wish to use a keytab, you can also configure authentik to authenticate using a password, or an existing credentials cache.
 
@@ -82,7 +82,7 @@ $ rm /tmp/authentik.keytab
 
 In authentik, configure these extra options:
 
--   SPNEGO keytab: the base64-encoded keytab created above.
+- SPNEGO keytab: the base64-encoded keytab created above.
 
 If you do not wish to use a keytab, you can also configure authentik to use an existing credentials cache.
 
@@ -100,8 +100,8 @@ If not specified, the server name defaults to trying out all entries in the keyt
 
 There are some extra settings you can configure:
 
--   Update internal password on login: when a user logs in to authentik using the Kerberos source as a password backend, their internal authentik password will be updated to match the one from Kerberos.
--   Use password writeback: when a user changes their password in authentik, their Kerberos password is automatically updated to match the one from authentik. This is only available if synchronization is configured.
+- Update internal password on login: when a user logs in to authentik using the Kerberos source as a password backend, their internal authentik password will be updated to match the one from Kerberos.
+- Use password writeback: when a user changes their password in authentik, their Kerberos password is automatically updated to match the one from authentik. This is only available if synchronization is configured.
 
 ## Kerberos source property mappings
 
@@ -113,14 +113,14 @@ By default, authentik ships with [pre-configured mappings](#built-in-property-ma
 
 Kerberos property mappings are used when you define a Kerberos source. These mappings define which Kerberos property maps to which authentik property. By default, the following mappings are created:
 
--   authentik default Kerberos User Mapping: Add realm as group
-    The realm of the user will be added as a group for that user.
--   authentik default Kerberos User Mapping: Ignore other realms
-    Realms other than the one configured on the source are ignored, and log in is not allowed.
--   authentik default Kerberos User Mapping: Ignore system principals
-    System principals such as `K/M` or `kadmin/admin` are ignored.
--   authentik default Kerberos User Mapping: Multipart principals as service accounts
-    Multipart principals (for example: `HTTP/authentik.company`) have their user type set to **service account**.
+- authentik default Kerberos User Mapping: Add realm as group
+  The realm of the user will be added as a group for that user.
+- authentik default Kerberos User Mapping: Ignore other realms
+  Realms other than the one configured on the source are ignored, and log in is not allowed.
+- authentik default Kerberos User Mapping: Ignore system principals
+  System principals such as `K/M` or `kadmin/admin` are ignored.
+- authentik default Kerberos User Mapping: Multipart principals as service accounts
+  Multipart principals (for example: `HTTP/authentik.company`) have their user type set to **service account**.
 
 These property mappings are configured with the most common Kerberos setups.
 
@@ -128,7 +128,7 @@ These property mappings are configured with the most common Kerberos setups.
 
 The following variable is available to Kerberos source property mappings:
 
--   `principal`: a Python string containing the Kerberos principal. For example `alice@REALM.COMPANY` or `HTTP/authentik.company@REALM.COMPANY`.
+- `principal`: a Python string containing the Kerberos principal. For example `alice@REALM.COMPANY` or `HTTP/authentik.company@REALM.COMPANY`.
 
 ## Troubleshooting