diff --git a/README.md b/README.md index c91f161..4e6bec3 100644 --- a/README.md +++ b/README.md @@ -1,3 +1,5 @@ # Tinyauth Docs This is the source code of the documentation site for my project [Tinyauth](https://github.com/steveiliop56/tinyauth). + +I18N, Translation FR added diff --git a/astro.config.mjs b/astro.config.mjs index 52d79bf..3be03a7 100644 --- a/astro.config.mjs +++ b/astro.config.mjs @@ -35,6 +35,11 @@ export default defineConfig({ Footer: "./src/components/footer.astro", }, title: "Tinyauth", + defaultLocale: 'root', + locales: { + root: { label: 'English', lang: 'en' }, + fr: { label: 'Français', lang: 'fr' }, + }, credits: true, logo: { src: "./public/tinyauth.png", @@ -197,10 +202,5 @@ export default defineConfig({ }, ], }), - umami({ - hostUrl: "https://analytics.doesmycode.work", - endpointUrl: "https://analytics.doesmycode.work", - id: "ed560a2b-b321-4745-b2f8-d7de846aeb7f", - }), ], }); diff --git a/package.json b/package.json index 9e8ced0..0b5cf5f 100644 --- a/package.json +++ b/package.json @@ -15,7 +15,7 @@ "@types/qrcode": "^1.5.6", "@yeskunall/astro-umami": "^0.0.8", "astro": "6.1.8", - "astro-mermaid": "^2.0.1", + "astro-mermaid": "2.1.0", "bcryptjs": "^3.0.3", "countup.js": "^2.10.0", "mermaid": "^11.14.0", @@ -27,4 +27,4 @@ "engines": { "node": "v25.5.0" } -} +} \ No newline at end of file diff --git a/pnpm-lock.yaml b/pnpm-lock.yaml index ca53ed2..5cddb47 100644 --- a/pnpm-lock.yaml +++ b/pnpm-lock.yaml @@ -21,8 +21,8 @@ importers: specifier: 6.1.8 version: 6.1.8(@types/node@25.7.0)(rollup@4.60.3) astro-mermaid: - specifier: ^2.0.1 - version: 2.0.1(astro@6.1.8(@types/node@25.7.0)(rollup@4.60.3))(mermaid@11.15.0) + specifier: 2.1.0 + version: 2.1.0(astro@6.1.8(@types/node@25.7.0)(rollup@4.60.3))(mermaid@11.15.0) bcryptjs: specifier: ^3.0.3 version: 3.0.3 @@ -916,8 +916,8 @@ packages: peerDependencies: astro: ^4.0.0-beta || ^5.0.0-beta || ^3.3.0 || ^6.0.0-beta - astro-mermaid@2.0.1: - resolution: {integrity: sha512-JTyB62FMFJpwS/1yUplmrugL0yr0flBVYZw6mf3s7pVlh+CHCeZTXyj3KCCWtFhnPLAdM+PYld0D+gxN/SysLQ==} + astro-mermaid@2.1.0: + resolution: {integrity: sha512-fFRUN0BTZh+DZhDiLyblXoO26XqJ1Rr+qK3JGgSu7OBspKHDm59jkztg/aHsrdo1vO/tIq/+xhP/vgT8Mp92XA==} peerDependencies: '@mermaid-js/layout-elk': ^0.2.0 astro: '>=4' @@ -2130,6 +2130,7 @@ packages: tsconfck@3.1.6: resolution: {integrity: sha512-ks6Vjr/jEw0P1gmOVwutM3B7fWxoWBL2KRDb1JfqGVawBmO5UsvmWOQFGHBPl5yxYz4eERr19E6L7NMv+Fej4w==} engines: {node: ^18 || >=20} + deprecated: unmaintained hasBin: true peerDependencies: typescript: ^5.0.0 @@ -3185,7 +3186,7 @@ snapshots: astro: 6.1.8(@types/node@25.7.0)(rollup@4.60.3) rehype-expressive-code: 0.41.7 - astro-mermaid@2.0.1(astro@6.1.8(@types/node@25.7.0)(rollup@4.60.3))(mermaid@11.15.0): + astro-mermaid@2.1.0(astro@6.1.8(@types/node@25.7.0)(rollup@4.60.3))(mermaid@11.15.0): dependencies: astro: 6.1.8(@types/node@25.7.0)(rollup@4.60.3) import-meta-resolve: 4.2.0 diff --git a/src/content/docs/fr/docs/__translated.log b/src/content/docs/fr/docs/__translated.log new file mode 100644 index 0000000..468de7a --- /dev/null +++ b/src/content/docs/fr/docs/__translated.log @@ -0,0 +1,30 @@ +about.mdx | 1e889f449f5781c37104f9fad86ebf05 +getting-started.mdx | b3b7fbd6b492e7801a5b02ed9913daca +reference/authentication.mdx | 564bab6b6e0ebd699ab03a5d48353722 +reference/cli.mdx | de1c9df802761e6c17b46a2154df21fd +reference/flow.mdx | b409573c18bf4d1e074d2b0c344f2f7a +reference/telemetry.mdx | 6bccf6ee6529b2102a60b941966febfa +reference/configuration.mdx | 879be81a8538a7e2fd34e845d72c14ad +reference/labels.mdx | f4c48667df3809d065d12aa18e9af6e5 +reference/headers.mdx | fa5ae5af5e8b980a3acc8c514e23e1e1 +reference/changelog.mdx | ccacf94861c67e850177a65b90eab1ea +integrations/zerobyte.mdx | bdfebd729458f1ccf700224241b8157c +contributing/contributing.mdx | 1117d6fcc0d32b5a03fa627fa6bdc756 +community/caddy.mdx | 710ea501a1cd18548103fcec7d76e862 +community/kubernetes.mdx | 64852f2004d533664e6d08b65933b536 +community/zitadel-oauth.mdx | 87d3b156a281bc9766dbba67108b3ae0 +guides/using-the-binary.mdx | 50b3931bfd96bc9a6af5f39f7b4504fd +guides/totp.mdx | e8be1169ed48c1bb18ccee71e2c9a9f8 +guides/ldap.mdx | a7e1a57c7b7a05cf42008c5715a00bd6 +guides/advanced.mdx | 53ebcfb055e8ced55920f4635aa0d1d3 +guides/pocket-id.mdx | e878532c0d9ce788e8bb9108cea75a9c +guides/github-oauth.mdx | 7fa3d1894e9aba9a7b93db6abd1d05b3 +guides/nginx-proxy-manager.mdx | 0f856cad69a3257483e11f08075e98d2 +guides/runtipi.mdx | fe4741add036704f5a27612e8647735e +guides/github-app-oauth.mdx | 5c3af2177ffa72fc159f12576b855c2d +guides/oidc.mdx | 31d911c3ebac4b3f8f0a63bb5b07ebcf +guides/access-controls.mdx | c6025b8b7f82077ae1f3768574820dff +guides/google-oauth.mdx | 0025aef51ecea6181957b57beacb7c7a +guides/other-oauth.mdx | 6b96c12dde8ed0b207cf69c9d3e0dc10 +breaking-updates/3-to-4.mdx | 9893d8c7366a64fe0938614b28b9ac0a +breaking-updates/4-to-5.mdx | 845a7fb26416ea0ebf77b4ce2de67eaa diff --git a/src/content/docs/fr/docs/__untranslated.log b/src/content/docs/fr/docs/__untranslated.log new file mode 100644 index 0000000..3f99702 --- /dev/null +++ b/src/content/docs/fr/docs/__untranslated.log @@ -0,0 +1 @@ +breaking-updates/4-to-5-migrator.astro | Erreur: Le fichier '4-to-5-migrator.astro' ne correspond à aucun pattern autorisé : *.txt, *.md*, *.json diff --git a/src/content/docs/fr/docs/about.mdx b/src/content/docs/fr/docs/about.mdx new file mode 100644 index 0000000..aaaf150 --- /dev/null +++ b/src/content/docs/fr/docs/about.mdx @@ -0,0 +1,22 @@ +--- +title: "À propos" +description: "Quelques mots sur Tinyauth." +--- + +Avant d'installer Tinyauth, il est naturel de se demander, _Pourquoi choisir Tinyauth plutôt que Authelia, Authentik ou Keycloak?_ C'est une question valable, et la réponse réside dans sa simplicité et son focus. + +## Le défi de l'authentification dans les homelabs + +Un middleware d'authentification est souvent utilisé pour protéger les applications qui ne disposent pas de screens de connexion intégrés ou pour ajouter une couche supplémentaire de sécurité. Alors que des projets comme Authelia, Authentik et Keycloak sont des solutions performantes, ils peuvent être difficiles à configurer pour les nouveaux utilisateurs, gourmands en ressources (car conçus pour un usage d'entreprise), ou lourds à mettre en place et à maintenir. Tinyauth répond à ces défis. + +## La motivation derrière Tinyauth + +Tinyauth a été développé comme un défi personnel pour créer une application robuste et résoudre les problèmes courants rencontrés avec les solutions d'authentification existantes. De nombreuses alternatives ne disposaient pas de support natif pour l'authentification directe de Traefik et nécessitaient des plugins et conteneurs supplémentaires. Tinyauth a été conçu autour de la simplicité comme principe fondamental — aucun tableau de bord complexe, aucun fichier de configuration intriqué, aucune dépendance externe. Tout est configuré à l'aide de variables d'environnement simples. + +## Cas d'utilisation appropriés + +Tinyauth n'est pas destiné aux environnements de production. Son objectif principal est d'ajouter un écran de connexion aux applications dans les homelabs ou de faciliter le partage de ressources avec la famille et les amis. Pour des scénarios nécessitant une gestion avancée des utilisateurs, Authentik est recommandé. + +## Orientation future + +Tinyauth a atteint un état mature, prenant en charge des fonctionnalités essentielles telles que OAuth, TOTP, LDAP et les contrôles d'accès. Il s'intègre parfaitement aux proxies populaires comme Nginx, Traefik et Caddy. L'accent restera sur le maintien de cette simplicité tout en introduisant des mises à jour améliorant la qualité de vie. Aucun plan n'est prévu pour introduire des tableaux de bord ou des fichiers de configuration complexes, préservant ainsi l'idée fondamentale du projet. \ No newline at end of file diff --git a/src/content/docs/fr/docs/breaking-updates/3-to-4.mdx b/src/content/docs/fr/docs/breaking-updates/3-to-4.mdx new file mode 100644 index 0000000..263169d --- /dev/null +++ b/src/content/docs/fr/docs/breaking-updates/3-to-4.mdx @@ -0,0 +1,179 @@ +--- +title: "Mise à jour de la version v3 vers v4" +description: "Un guide pour aider à migrer de Tinyauth v3 vers v4." +--- + +Tinyauth v4 introduit plusieurs changements majeurs qui nécessitent une migration manuelle. Ce guide décrit les mises à jour nécessaires pour une mise à niveau fluide. + +## SQLite Database + +À partir de la version 4, Tinyauth est une application avec état qui utilise une base de données SQLite pour stocker les sessions. Ce changement améliore la sécurité. Pour les configurations Docker, incluez le volume suivant : + +```yaml +services: + tinyauth: + volumes: + - ./data:/data +``` + +Pour les installations binaires, le chemin de la base de données peut être modifié à l'aide de l'option suivante : + +| Environnement | Indicateur | Description | Valeur par défaut | Requis | +| --------------- | ----------------- | -------------------------------------------------- | ------------------- | -------- | +| `DATABASE_PATH` | `--database-path` | Le chemin où la base de données SQLite sera stockée. | `/data/tinyauth.db` | no | + +:::note + La base de données SQLite ne stocke pas les options de configuration. Toute la configuration est toujours effectuée à l'aide de variables d'environnement ou de drapeaux CLI. Si la persistance des sessions entre les redémarrages n'est pas une préoccupation, le volume de la base de données peut être omis. +::: + +## OAuth + +Le backend OAuth a été réécrit pour prendre en charge plusieurs fournisseurs OAuth. Les options suivantes sont obsolètes : + +- `GITHUB_CLIENT_ID`/`--github-client-id` +- `GITHUB_CLIENT_SECRET`/`--github-client-secret` +- `GITHUB_CLIENT_SECRET_FILE`/`--github-client-secret-file` +- `GOOGLE_CLIENT_ID`/`--google-client-id` +- `GOOGLE_CLIENT_SECRET`/`--google-client-secret` +- `GOOGLE_CLIENT_SECRET_FILE`/`--google-client-secret-file` +- `GENERIC_CLIENT_ID`/`--generic-client-id` +- `GENERIC_CLIENT_SECRET`/`--generic-client-secret` +- `GENERIC_CLIENT_SECRET_FILE`/`--generic-client-secret-file` +- `GENERIC_AUTH_URL`/`--generic-auth-url` +- `GENERIC_TOKEN_URL`/`--generic-token-url` +- `GENERIC_USER_URL`/`--generic-user-url` +- `GENERIC_SCOPES`/`--generic-scopes` +- `GENERIC_NAME`/`--generic-name` +- `GENERIC_SKIP_SSL`/`--generic-skip-ssl` + +La nouvelle configuration pour les fournisseurs OAuth inclut un nom dynamique dans la clé de configuration (ID du fournisseur) qui sera utilisé pour les URL de rappel et l'identification au sein des points d'API. Les nouvelles options de configuration sont : + +| Environnement | Indicateur | Description | Valeur par défaut | Requis | +| ------------------------------------------- | --------------------------------------------- | ------------------------------------------------------------------- | ------------------------------------------ | -------- | +| `PROVIDERS_[PROVIDER]_CLIENT_ID` | `--providers-[provider]-client-id` | L'ID du client pour le client OAuth. | `` | yes | +| `PROVIDERS_[PROVIDER]_CLIENT_SECRET` | `--providers-[provider]-client-secret` | Le secret du client pour le client OAuth. | `` | yes | +| `PROVIDERS_[PROVIDER]_CLIENT_SECRET_FILE` | `--providers-[provider]-client-secret-file` | Un chemin vers un fichier contenant le secret du client OAuth. | `` | no | +| `PROVIDERS_[PROVIDER]_SCOPES` | `--providers-[provider]-scopes` | Les scopes nécessaires pour le fournisseur OAuth. | `` | yes | +| `PROVIDERS_[PROVIDER]_REDIRECT_URL` [^1] | `--providers-[provider]-redirect-url` | L'URL de redirection pour le fournisseur OAuth. | `` | yes | +| `PROVIDERS_[PROVIDER]_AUTH_URL` | `--providers-[provider]-auth-url` | L'URL d'authentification pour le fournisseur OAuth. | `` | yes | +| `PROVIDERS_[PROVIDER]_TOKEN_URL` | `--providers-[provider]-token-url` | L'URL de token pour le fournisseur OAuth. | `` | yes | +| `PROVIDERS_[PROVIDER]_USER_INFO_URL` [^2] | `--providers-[provider]-user-info-url` | L'URL d'information utilisateur pour le fournisseur OAuth. | `` | yes | +| `PROVIDERS_[PROVIDER]_INSECURE_SKIP_VERIFY` | `--providers-[provider]-insecure-skip-verify` | Ignorer la vérification du certificat SSL pour le fournisseur. | `false` | no | +| `PROVIDERS_[PROVIDER]_NAME` | `--providers-[provider]-name` | Le nom du fournisseur OAuth (pour le bouton UI). | Provider ID with first letter capitalized. | no | + +[^1]: Ceci est requis pour le moment. Bien que certains fournisseurs gèrent cela automatiquement, il est suggéré de le définir quand même. + +[^2]: Veuillez noter l'ajout de `_INFO_` dans le nom de cette option. + +Par exemple, pour configurer Google OAuth : + +``` +PROVIDERS_GOOGLE_CLIENT_ID=my-client-id +PROVIDERS_GOOGLE_CLIENT_SECRET=my-client-secret +``` + +Ou avec les drapeaux CLI : + +``` +--providers-google-client-id=my-client-id --providers-google-client-secret=my-client-secret +``` + +:::caution + Assurez-vous de modifier les URLs de rappel dans les paramètres de votre fournisseur OAuth pour correspondre à l'ID du fournisseur. Par exemple, si votre configuration est `PROVIDERS_GOOGLE_CLIENT_ID`, l'ID du fournisseur est `google` et l'URL de rappel est `https://tinyauth.example.com/api/oauth/callback/google`. +::: + +:::note + L'utilisation de `google` ou `github` comme ID de fournisseur déclenche le remplissage automatique des informations requises (par exemple, l'URL de redirection, les scopes). Vous n'aurez à fournir que l'ID du client et le secret. +::: + +## Labels + +Les étiquettes ont été restructurées. Les étiquettes obsolètes incluent : + +- `tinyauth.users` +- `tinyauth.allowed` +- `tinyauth.headers` +- `tinyauth.domain` +- `tinyauth.basic.password.plain` +- `tinyauth.basic.password.file` +- `tinyauth.basic.username` +- `tinyauth.oauth.whitelist` +- `tinyauth.oauth.groups` +- `tinyauth.ip.allow` +- `tinyauth.ip.block` +- `tinyauth.ip.bypass` + +La nouvelle structure utilise des identifiants spécifiques à l'application : + +| Nom | Description | +| ----------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | +| `tinyauth.apps.[app].config.domain` | Le domaine où l'application protégée est exposée. Tinyauth utilisera cela pour identifier le conteneur approprié. | +| `tinyauth.apps.[app].users.allow` | Une liste séparée par des virgules d'utilisateurs autorisés à accéder à l'application. | +| `tinyauth.apps.[app].users.block` | Une liste séparée par des virgules d'utilisateurs non autorisés à accéder à l'application. | +| `tinyauth.apps.[app].oauth.whitelist` | Une liste séparée par des virgules ou une expression régulière d'adresses e-mail autorisées à accéder à l'application (provenant d'OAuth). | +| `tinyauth.apps.[app].oauth.groups` | Une liste séparée par des virgules de groupes OAuth requis pour qu'un utilisateur accède à l'application. | +| `tinyauth.apps.[app].ip.allow` | Une liste séparée par des virgules d'adresses IP ou de CIDR autorisées à accéder à l'application. | +| `tinyauth.apps.[app].ip.block` | Une liste séparée par des virgules d'adresses IP ou de CIDR non autorisées à accéder à l'application. | +| `tinyauth.apps.[app].ip.bypass` | Une liste séparée par des virgules d'adresses IP ou de CIDR pour lesquelles l'authentification ne sera pas requise afin d'accéder à l'application. | +| `tinyauth.apps.[app].response.headers` | Une liste séparée par des virgules d'en-têtes que Tinyauth inclura dans sa réponse (utile pour l'authentification aux applications protégées avec des jetons). | +| `tinyauth.apps.[app].response.basicauth.username` | Nom d'utilisateur utilisé par Tinyauth pour s'authentifier à une application cible via l'authentification basique. | +| `tinyauth.apps.[app].response.basicauth.password` | Mot de passe utilisé par Tinyauth pour s'authentifier à une application cible via l'authentification basique. | +| `tinyauth.apps.[app].response.basicauth.passwordfile` | Un chemin vers un fichier contenant le mot de passe utilisé par Tinyauth pour s'authentifier à une application cible via l'authentification basique. | +| `tinyauth.apps.[app].path.allow` | Une expression régulière des chemins qui ne nécessitent pas d'authentification. | +| `tinyauth.apps.[app].path.block` | Une expression régulière des chemins qui nécessiteront une authentification (signifiant que tous les autres chemins sont autorisés). | + +Par exemple, si votre configuration actuelle ressemble à ceci : + +```yaml +services: + whoami: + labels: + tinyauth.users: user1,user2 +``` + +Vous devrez également le modifier : + +```yaml +services: + whoami: + labels: + tinyauth.apps.whoami.users.allow: user1,user2 +``` + +:::note + Le mécanisme de découverte des étiquettes utilise désormais le nom de l'application dans le sous-domaine de la requête. Par exemple, `myapp.example.com` correspond à `tinyauth.apps.myapp.foo: bar`. La découverte d'étiquettes basée sur le nom du conteneur n'est plus prise en charge. +::: + +:::note + Il est conseillé de passer à l'étiquette `tinyauth.apps.[app].config.domain` pour une meilleure découverte. +::: + +## Configuration Changes + +Les options suivantes sont obsolètes : + +- `SECRET`/`--secret` +- `SECRET_FILE`/`--secret-file` +- `DISABLE_CONTINUE`/`--disable-continue` + +Options modifiées : + +| Actuel | Nouveau | Valeurs | +| ----------------------------------- | ----------------------------------- | ----------------------------------------------------------- | +| `COOKIE_SECURE` (`--cookie-secure`) | `SECURE_COOKIE` (`--secure-cookie`) | `true`, `false` | +| `LOG_LEVEL` (`--log-level`) | `LOG_LEVEL` (`--log-level`) | `trace`, `debug`, `info`, `warn`, `error`, `fatal`, `panic` | + +## API Changes + +L'API a été mise à jour. Si vous utilisez l'API directement, veuillez consulter les sources du [contrôleur](https://github.com/steveiliop56/tinyauth/tree/main/internal/controller). Tous les chemins d'API ont le préfixe `/api`. Plus important encore, le chemin de vérification de santé a changé. + +| Chemin actuel | Nouveau chemin | Méthode | +| ------------------ | -------------- | ------ | +| `/api/healthcheck` | `/api/healthz` | `GET` | +| `/api/healthcheck` | `/api/healthz` | `HEAD` | + +Il existe également une nouvelle commande `tinyauth healthcheck` qui vérifiera automatiquement si le serveur est en bonne santé en utilisant votre configuration actuelle. L'image Docker inclut la vérification de santé suivante : + +```dockerfile +HEALTHCHECK --interval=30s --timeout=5s --start-period=5s --retries=3 CMD ["tinyauth", "healthcheck"] +``` diff --git a/src/content/docs/fr/docs/breaking-updates/4-to-5-migrator.astro b/src/content/docs/fr/docs/breaking-updates/4-to-5-migrator.astro new file mode 100644 index 0000000..0c3ffea --- /dev/null +++ b/src/content/docs/fr/docs/breaking-updates/4-to-5-migrator.astro @@ -0,0 +1,43 @@ +--- + +--- + + + +
+
+ + 
TINYAUTH_SERVER_PORT=8080
--server.address=0.0.0.0
+
+ +
diff --git a/src/content/docs/fr/docs/breaking-updates/4-to-5.mdx b/src/content/docs/fr/docs/breaking-updates/4-to-5.mdx new file mode 100644 index 0000000..c3698a9 --- /dev/null +++ b/src/content/docs/fr/docs/breaking-updates/4-to-5.mdx @@ -0,0 +1,50 @@ +--- +title: "Mise à jour de la version 4 vers la version 5" +description: "Un guide pour aider à migrer depuis Tinyauth v4 vers v5." +--- + +import ConfigMigrator from "./4-to-5-migrator.astro"; + +:::note +Pour suivre ce guide de migration, vous devez avoir Tinyauth v4 en cours d'exécution. Si vous venez de Tinyauth v3, vous devez d'abord migrer vers la version 4. Pour migrer depuis Tinyauth v3, veuillez consulter le [guide de migration](/docs/breaking-updates/3-to-4). +::: + +Tinyauth v5 introduit uniquement des changements de configuration. + +## Changements de configuration + +Dans Tinyauth v4, la configuration était un désordre – certaines options ne fonctionnaient pas comme prévu, il était difficile de les suivre et elles étaient généralement peu intuitives. Dans Tinyauth v5, nous avons simplifié le format de configuration en un schéma unique à travers tous les moyens de configuration. + +### Variables d'environnement + +Les variables d'environnement suivent désormais le format suivant : + +``` +TINYAUTH_
_= +``` + +Le préfixe `TINYAUTH_` est utilisé pour distinguer la configuration de Tinyauth des autres variables d'environnement. Toutes les variables d'environnement préfixées par `TINYAUTH_` sont considérées comme des options de configuration et, en cas de mauvaise configuration, contrairement aux versions précédentes, Tinyauth refusera de démarrer. + +### Options CLI + +Les options CLI suivent le format suivant : + +``` +--section.key=value +``` + +Ce format peut sembler peu intuitif au premier abord, mais il est en réalité très puissant et meilleur que le format précédent basé sur des délimiteurs. Il vous permet de spécifier les options de configuration d'une manière facile à retenir et à taper. + +### Migrateur de configuration + +Étant donné que le format complet de la configuration a changé, vous devrez mettre à jour l'ensemble de votre configuration. Pour faciliter ce processus, nous avons fourni un migrateur de configuration qui peut vous aider à migrer vos options CLI et variables d'environnement vers le nouveau format. + + + +:::caution +La configuration dynamique n'est pas prise en charge par ce migrateur. Vous devrez mettre à jour manuellement vos fichiers de configuration et variables d'environnement pour utiliser le nouveau format. Pour plus d'informations, consultez la référence [configuration](/docs/reference/configuration). +::: + +:::note +Pour que le migrateur fonctionne correctement, veuillez spécifier une variable d'environnement ou une option CLI par ligne (séparée par le signe égal **et non** l'espace). Bien que le migrateur prenne en charge les commentaires et les lignes vides, il est recommandé de garder l'entrée propre et facile à lire. De plus, vous devriez idéalement ne pas mélanger options CLI et variables d'environnement en une seule fois (même si le migrateur les prend en charge). +::: \ No newline at end of file diff --git a/src/content/docs/fr/docs/community/caddy.mdx b/src/content/docs/fr/docs/community/caddy.mdx new file mode 100644 index 0000000..c35d72b --- /dev/null +++ b/src/content/docs/fr/docs/community/caddy.mdx @@ -0,0 +1,133 @@ +--- +title: "Caddy" +description: "Apprenez à configurer Tinyauth avec le proxy inverse Caddy." +--- + +_Contributeur : [@erwinkramer](https://github.com/erwinkramer)_ + +Une configuration Caddy pour Docker Compose, basée sur [caddy-docker-proxy](https://github.com/lucaslorentz/caddy-docker-proxy), qui fonctionne avec Tinyauth pour permettre une configuration entièrement étiquetée. + +## Authentication Snippet + +Ajoutez les étiquettes suivantes n'importe où dans le fichier Compose sous un service. Cela crée un [fragment](https://caddyserver.com/docs/caddyfile/concepts#snippets) réutilisable, appelé `tinyauth_forwarder`, pour transférer l'authentification : + +```yaml +caddy: (tinyauth_forwarder) +caddy.forward_auth: tinyauth:3000 +caddy.forward_auth.uri: /api/auth/caddy +``` + +Cela donne le fragment suivant : + +```typescript +(tinyauth_forwarder) { + forward_auth tinyauth:3000 { + uri /api/auth/caddy + } +} +``` + +## Caddy Configuration + +Le service `caddy-docker-proxy` pourrait ressembler à ceci si les étiquettes sont ajoutées : + +```yaml +services: + caddy: + image: lucaslorentz/caddy-docker-proxy:2.10.0 + restart: unless-stopped + ports: + - 80:80 + - 443:443 + volumes: + - /var/run/docker.sock:/var/run/docker.sock + - caddy-data:/data + labels: + caddy: (tinyauth_forwarder) + caddy.forward_auth: tinyauth:3000 + caddy.forward_auth.uri: /api/auth/caddy + +volumes: + caddy-data: +``` + +## Tinyauth Configuration + +Ajoutez Tinyauth et placez-le derrière Caddy avec les étiquettes `caddy` et `caddy.reverse_proxy` : + +```yaml +services: + tinyauth: + image: ghcr.io/steveiliop56/tinyauth:v5 + restart: unless-stopped + environment: + - TINYAUTH_APPURL=http://auth.example.com + - TINYAUTH_AUTH_USERS=your-username-password-hash + labels: + caddy: http://auth.example.com + caddy.reverse_proxy: "{{upstreams 3000}}" +``` + +## Securing a Service + +Placez n'importe quel service derrière Tinyauth. La seule addition requise pour sécuriser un service est le fragment réutilisable, `tinyauth_forwarder`, créé précédemment : + +```yaml +caddy.import: tinyauth_forwarder * +``` + +En utilisant Whoami comme exemple, cela pourrait ressembler à ceci : + +```yaml +services: + whoami: + image: traefik/whoami:latest + restart: unless-stopped + labels: + caddy: http://whoami.example.com + caddy.reverse_proxy: "{{upstreams 80}}" + caddy.import: tinyauth_forwarder * +``` + +## Complete Example + +Voici un exemple complet avec tous les services réunis : + +```yaml +services: + caddy: + image: lucaslorentz/caddy-docker-proxy:2.10.0 + restart: unless-stopped + ports: + - 80:80 + - 443:443 + volumes: + - /var/run/docker.sock:/var/run/docker.sock + - caddy-data:/data + labels: + caddy: (tinyauth_forwarder) + caddy.forward_auth: tinyauth:3000 + caddy.forward_auth.uri: /api/auth/caddy + caddy.forward_auth.copy_headers: Remote-User Remote-Name Remote-Email Remote-Groups # optional when you want to make headers available to your service + + tinyauth: + image: ghcr.io/steveiliop56/tinyauth:v5 + restart: unless-stopped + environment: + - TINYAUTH_APPURL=http://auth.example.com + - TINYAUTH_AUTH_USERS=your-username-password-hash + labels: + caddy: http://auth.example.com + caddy.reverse_proxy: "{{upstreams 3000}}" + + whoami: + image: traefik/whoami:latest + restart: unless-stopped + labels: + caddy: http://whoami.example.com + caddy.reverse_proxy: "{{upstreams 80}}" + caddy.import: tinyauth_forwarder * + +volumes: + caddy-data: +``` \ No newline at end of file diff --git a/src/content/docs/fr/docs/community/kubernetes.mdx b/src/content/docs/fr/docs/community/kubernetes.mdx new file mode 100644 index 0000000..44ca5e3 --- /dev/null +++ b/src/content/docs/fr/docs/community/kubernetes.mdx @@ -0,0 +1,228 @@ +--- +title: "Apprenez à configurer Tinyauth avec des ressources Kubernetes." +description: "Découvrez comment mettre en place Tinyauth avec des ressources Kubernetes." +--- + +_Contributors: [@kdwils](https://github.com/kdwils), [@pushpinderbal](https://github.com/pushpinderbal)_ + +## Cas d'utilisation + +Les applications hébergées sur Kubernetes sont généralement exposées à l'extérieur via les [Contrôleurs Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/) ou la nouvelle [Gateway API](https://kubernetes.io/docs/concepts/services-networking/gateway/). Ceux-ci peuvent agir comme une passerelle pour appliquer des politiques d'authentification et d'autorisation avant que le trafic n'atteigne vos applications auto-hébergées. Cela est utile pour protéger les outils internes, les interfaces d'administration ou les services exposés à Internet - sans avoir besoin de modifier les applications elles-mêmes, en particulier celles qui ne disposent pas de mécanismes d'authentification intégrés. + +Les reverse proxies populaires tels que Nginx, Traefik et Envoy fournissent des implémentations de contrôleur Ingress et Gateway API pour Kubernetes pouvant être intégrées à Tinyauth. + +## Prérequis + +Ce guide suppose les prérequis suivants : + +- Un cluster Kubernetes opérationnel +- Un contrôleur Ingress ou une implémentation de Gateway API fonctionnelle (ce guide démontre `ingress-nginx` et `Istio`, mais `traefik` peut également être utilisé). +- Expérience avec Kubernetes + +## Créer un namespace + +Tout d'abord, créez un namespace pour Tinyauth : + +```yaml +apiVersion: v1 +kind: Namespace +metadata: + name: tinyauth +``` + +## Créer un déploiement + +Créez le déploiement de Tinyauth : + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: tinyauth + labels: + app: tinyauth +spec: + replicas: 1 + selector: + matchLabels: + app: tinyauth + template: + metadata: + labels: + app: tinyauth + spec: + containers: + - name: tinyauth + image: ghcr.io/steveiliop56/tinyauth:v5 + ports: + - containerPort: 3000 + env: + - name: TINYAUTH_APPURL + value: http://auth.example.com + - name: TINYAUTH_AUTH_USERS + value: user:$$2a$$10$$UdLYoJ5lgPsC0RKqYH/jMua7zIn0g9kPqWmhYayJYLaZQ/FTmH2/u # Username is user and password is password + livenessProbe: + exec: + command: + - tinyauth + - healthcheck + initialDelaySeconds: 10 + periodSeconds: 30 + readinessProbe: + exec: + command: + - tinyauth + - healthcheck + initialDelaySeconds: 5 + periodSeconds: 10 +``` + +## Créer un service + +Créez le service : + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: tinyauth +spec: + selector: + app: tinyauth + ports: + - port: 3000 + targetPort: 3000 + type: ClusterIP +``` + +## Utilisation avec ingress-nginx + +:::caution +`ingress-nginx` est prévu pour être retiré en mars 2026 (https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/). Envisagez de migrer vers un composant Ingress pris en charge. +::: + +Cette ressource Ingress configure `ingress-nginx` pour transmettre les vérifications d'authentification pour l'hôte `my-host.domain.com` vers une URL spécifique (`auth-url`). Si l'utilisateur n'est pas authentifié, il sera redirigé vers une page de connexion (`auth-signin`). + +La documentation sur ces annotations se trouve dans le dépôt ingress-nginx [annotations.md](https://github.com/kubernetes/ingress-nginx/blob/main/docs/user-guide/nginx-configuration/annotations.md#annotations). + +- `nginx.ingress.kubernetes.io/auth-url` indique l'URL vers laquelle `ingress-nginx` doit envoyer les requêtes pour vérifier si l'utilisateur est authentifié. +- `nginx.ingress.kubernetes.io/auth-signin` indique l'URL vers laquelle `ingress-nginx` doit envoyer les utilisateurs non authentifiés pour se connecter. +- `nginx.ingress.kubernetes.io/auth-signin-redirect-param` indique la clé du paramètre de requête utilisé pour définir l'URI de redirection. + +:::note +Cet exemple utilise l'URI en cluster <my-service>.<my-namespace>.svc.cluster.local basé sur l'exemple ci-dessus pour le `auth-url`. L'annotation `auth-signin` doit être une référence à une URI accessible aux utilisateurs. +::: + +```yaml +apiVersion: networking.k8s.io/v1 +kind: Ingress +metadata: + name: my-ingress + namespace: my-namespace + annotations: + nginx.ingress.kubernetes.io/auth-url: "http://tinyauth.tinyauth.svc.cluster.local:3000/api/auth/nginx" + nginx.ingress.kubernetes.io/auth-signin: "http://auth.example.com/login" + nginx.ingress.kubernetes.io/auth-signin-redirect-param: redirect_uri +spec: + ingressClassName: nginx + rules: + - host: my-host.example.com + http: + paths: + - path: / + pathType: Prefix + backend: + service: + name: my-service + port: + number: 8080 +``` + +## Utilisation avec Istio + +L'autorisation externe dans Istio est configurée à l'aide du CRD `AuthorizationPolicy` et peut être mise en place pour utiliser Tinyauth comme fournisseur d'autorisation externe pour les ressources Ingress et Gateway API. Istio utilise Envoy proxy sous le capot, cette configuration peut donc également être adaptée aux filtres [Envoy](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/ext_authz_filter) autonomes. + +### Définir l'autorisateur externe + +Ajoutez Tinyauth comme fournisseur d'autorisation externe dans votre configuration de maillage Istio. + +:::note +Cet exemple utilise l'URI en cluster <my-service>.<my-namespace>.svc.cluster.local avec l'hypothèse que Istio et Tinyauth existent dans le même cluster Kubernetes et que le service Tinyauth est accessible depuis les pods d'ingress Istio. L'URL accessible aux utilisateurs finaux (par ex., `http://auth.example.com`) est configurée avec `TINYAUTH_APPURL`. +::: + +```yaml +extensionProviders: +- name: "tinyauth" + envoyExtAuthzHttp: + service: "tinyauth.tinyauth.svc.cluster.local" + port: "3000" + pathPrefix: "/api/auth/envoy?path=" + includeRequestHeadersInCheck: ["cookie", "x-forwarded-for", "x-forwarded-proto", "x-forwarded-host", "accept", "user-agent"] + includeAdditionalHeadersInCheck: + "x-forwarded-proto": "%REQ(:SCHEME)%" + "x-forwarded-host": "%REQ(:AUTHORITY)%" + "x-forwarded-uri": "%REQ(:PATH)%" + "x-forwarded-method": "%REQ(:METHOD)%" + headersToDownstreamOnAllow: ["set-cookie"] + headersToDownstreamOnDeny: ["content-type", "set-cookie"] +``` + +:::note +- Envoy transmet les requêtes à l'autorisateur externe avec le chemin d'origine de la requête client. La configuration `pathPrefix` ci-dessus préfixe le chemin avec un point de terminaison que Tinyauth reconnaît, tandis que Tinyauth ignore le chemin d'origine. +- Contrairement aux autres implémentations de proxy, Envoy se connecte au backend d'autorisation externe en utilisant la méthode HTTP originale de la requête client et ne peut pas être configuré pour utiliser une méthode statique. Tinyauth gère cela en autorisant toutes les méthodes HTTP standard sur le point de terminaison `/api/auth/envoy`. Voir [envoyproxy/envoy#5357](https://github.com/envoyproxy/envoy/issues/5357) pour plus d'informations relatives à ce comportement. +::: + +Si vous installez Istio via Helm, vous pouvez fournir la configuration `extensionProviders` dans les fichiers `values.yaml` comme suit : + +```yaml +meshConfig: + extensionProviders: + - name: "tinyauth" + ........ +``` + +### Créer une politique d'autorisation + +Étant donné que vous avez un `HTTPRoute` sous un Gateway qui expose votre application, vous pouvez maintenant créer une `AuthorizationPolicy` pour le protéger en utilisant Tinyauth. + +```yaml +apiVersion: gateway.networking.k8s.io/v1 +kind: HTTPRoute +metadata: + name: myapp-http-route + labels: + app: myapp +spec: + parentRefs: + - name: my-public-gateway + namespace: ingress + sectionName: https + hostnames: + - myapp.example.com + rules: + - backendRefs: + - name: myapp-service + port: 80 +``` + +```yaml +apiVersion: security.istio.io/v1 +kind: AuthorizationPolicy +metadata: + name: tinyauth-policy + namespace: ingress +spec: + targetRefs: + - kind: Gateway + group: gateway.networking.k8s.io + name: my-public-gateway + action: CUSTOM + provider: + name: "tinyauth" + rules: + - to: + - operation: + hosts: ["myapp.example.com"] +``` + +Pour plus d'informations, reportez-vous à la documentation Istio sur l'[Autorisation externe](https://istio.io/latest/docs/tasks/security/authorization/authz-custom/) et la [Politique d'autorisation](https://istio.io/latest/docs/reference/config/security/authorization-policy/). \ No newline at end of file diff --git a/src/content/docs/fr/docs/community/zitadel-oauth.mdx b/src/content/docs/fr/docs/community/zitadel-oauth.mdx new file mode 100644 index 0000000..3373177 --- /dev/null +++ b/src/content/docs/fr/docs/community/zitadel-oauth.mdx @@ -0,0 +1,68 @@ +--- +title: "Zitadel" +description: "Apprenez à configurer Tinyauth avec le fournisseur OAuth Zitadel." +--- + +_Contributeur : [@WilliamB78](https://github.com/WilliamB78)._ + +Tinyauth prend en charge n’importe quel fournisseur OAuth générique. Ce guide montre comment utiliser Zitadel pour authentifier les utilisateurs. + +## Exigences + +- Un nom de domaine (gTLD requis) +- Une instance Zitadel (cloud ou auto-hébergée) + +## Création de l'application OAuth Zitadel + +Commencez par créer une application dans Zitadel. Visitez la Console Zitadel et créez un nouveau projet. Pour le nom du projet utilisez Tinyauth et pour le framework sélectionnez « autre ». + +![Nouveau projet Zitadel](/screenshots/zitadel/project-new.png) + +Ensuite, créez une nouvelle application en cliquant sur le bouton **+**. Suivez l’assistant et configurez l’application comme suit : + +| Nom | Valeur | +| --------------------- | --------------------------------------------------------- | +| Nom | Tinyauth | +| Type | Web | +| Types de Grant | Authorization Code | +| Types de Réponse | Code | +| Méthode d'Authentification | Basic | +| URI de Redirection | `https://tinyauth.example.com/api/oauth/callback/zitadel` | + +![Nouvelle application Zitadel](/screenshots/zitadel/app-new.png) + +Finalisez en cliquant sur le bouton **Create**. Copiez l’ID client et le secret client. + +![Identifiants de l’application Zitadel](/screenshots/zitadel/app-creds.png) + +## Configuration de Tinyauth + +Pour intégrer Zitadel à Tinyauth, ajoutez les variables d’environnement suivantes au conteneur Docker Tinyauth : + +```yaml +services: + tinyauth: + environment: + - TINYAUTH_OAUTH_PROVIDERS_ZITADEL_SCOPES=openid profile email preferred_username groups + - TINYAUTH_OAUTH_PROVIDERS_ZITADEL_AUTHURL=https://zitadel.example.com/oauth/v2/authorize + - TINYAUTH_OAUTH_PROVIDERS_ZITADEL_TOKENURL=https://zitadel.example.com/oauth/v2/token + - TINYAUTH_OAUTH_PROVIDERS_ZITADEL_USERINFOURL=https://zitadel.example.com/oidc/v1/userinfo + - TINYAUTH_OAUTH_PROVIDERS_ZITADEL_REDIRECTURL=https://tinyauth.example.com/api/oauth/callback/zitadel + - TINYAUTH_OAUTH_PROVIDERS_ZITADEL_CLIENTID=your-zitadel-client-id + - TINYAUTH_OAUTH_PROVIDERS_ZITADEL_CLIENTSECRET=your-zitadel-client-secret + - TINYAUTH_OAUTH_PROVIDERS_ZITADEL_NAME=Zitadel +``` + +:::note + Zitadel doit être accessible via HTTPS et un certificat de confiance. En cas d’impossibilité (par ex. certificats auto-signés), vous devrez utiliser `TINYAUTH_OAUTH_PROVIDERS_ZITADEL_INSECURE=true` afin que Tinyauth ignore la vérification du certificat. +::: + +:::caution + OAuth seul ne garantit pas la sécurité. Par défaut, tout compte Zitadel peut se connecter en tant qu’utilisateur normal. Pour restreindre l’accès, utilisez la variable d’environnement `TINYAUTH_OAUTH_WHITELIST` afin de permettre uniquement des adresses e‑mail spécifiques. Reportez‑vous à la page [configuration](/docs/reference/configuration) pour plus de détails. +::: + +:::note + Avec OAuth activé, les variables d’environnement `TINYAUTH_AUTH_USERS` ou `TINYAUTH_AUTH_USERSFILE` peuvent être supprimées afin de permettre uniquement la connexion via le fournisseur OAuth. +::: + +Redémarrez Tinyauth. Lors de la visite de l’écran de connexion, une option supplémentaire pour se connecter avec Zitadel apparaîtra. \ No newline at end of file diff --git a/src/content/docs/fr/docs/contributing/contributing.mdx b/src/content/docs/fr/docs/contributing/contributing.mdx new file mode 100644 index 0000000..78057a9 --- /dev/null +++ b/src/content/docs/fr/docs/contributing/contributing.mdx @@ -0,0 +1,75 @@ +--- +title: "Contribuer" +description: "Vous souhaitez contribuer à Tinyauth ? Voici les étapes pour commencer." +--- + +Contribuer à Tinyauth est simple. Suivez les étapes ci-dessous pour configurer un serveur de développement. + +:::note +Si vous utilisez des modèles de langage étendus pour contribuer au projet, veuillez vous assurer d'avoir lu et compris la [Politique IA](AI_POLICY.md). +::: + +## Requirements + +- pnpm +- Golang v1.24.0 ou plus récent +- Git +- Docker +- Make + +## Cloning the Repository + +Commencez par cloner le dépôt : + +```sh +git clone https://github.com/tinyauthapp/tinyauth +cd tinyauth +``` + +## Installing Dependencies + +Bien que le développement se fasse dans Docker, il est recommandé d'installer les dépendances localement pour éviter des erreurs d'importation. Installez les dépendances Go : + +```sh +go mod tidy +``` + +Les dépendances front-end peuvent être installées comme suit : + +```sh +cd frontend/ +pnpm ci +``` + +## Create the `.env` file + +La configuration nécessite un fichier d'environnement. Copiez le fichier `.env.example` vers `.env` et ajustez les variables d'environnement selon vos besoins. + +## Development Workflow + +Le flux de travail de développement est conçu pour fonctionner entièrement dans Docker, garantissant la compatibilité avec Traefik et éliminant le besoin de compilations locales. Une configuration recommandée consiste à pointer un sous-domaine vers votre machine locale : + +``` +*.dev.example.com -> 127.0.0.1 +dev.example.com -> 127.0.0.1 +``` + +:::note +Un domaine provenant de [sslip.io](https://sslip.io) peut être utilisé si un domaine personnalisé n'est pas disponible. Par exemple, définissez le domaine Tinyauth sur `tinyauth.127.0.0.1.sslip.io` et le domaine whoami sur `whoami.127.0.0.1.sslip.io`. +::: + +Assurez-vous que les domaines sont correctement configurés dans le fichier Docker Compose de développement, puis démarrez l'environnement de développement : + +```sh +make dev +``` + +Si vous avez besoin de compiler le binaire localement, vous pouvez exécuter : + +```sh +make binary +``` + +:::note +Il est recommandé de copier le fichier d'exemple `docker-compose.dev.yml` vers `docker-compose.test.yml` afin d'éviter les commits accidentels d'informations sensibles. La recette make utilisera automatiquement `docker-compose.test.yml` ainsi que `docker-compose.test.prod.yml` (pour la recette `make prod`) s'il existe. +::: \ No newline at end of file diff --git a/src/content/docs/fr/docs/getting-started.mdx b/src/content/docs/fr/docs/getting-started.mdx new file mode 100644 index 0000000..012e98b --- /dev/null +++ b/src/content/docs/fr/docs/getting-started.mdx @@ -0,0 +1,143 @@ +--- +title: "Commencer" +description: "Apprenez à configurer et déployer Tinyauth." +--- + +import { Tabs, TabItem } from '@astrojs/starlight/components'; +import CreateUserTool from "../../../../components/create-user-tool.astro"; + +:::note + Par défaut, Tinyauth s'intègre avec le reverse proxy Traefik. Pour les proxys alternatifs, des guides détaillés sont disponibles pour [Nginx Proxy Manager](/docs/guides/nginx-proxy-manager) et [Caddy](/docs/community/caddy). +::: + +:::note + Vous utilisez Kubernetes ? Découvrez le guide [Kubernetes](/docs/community/kubernetes) et le (expérimental) [Helm chart](https://helm.tinyauth.app). +::: + +## Ressources communautaires + +- Un tutoriel par [Jim's Garage](https://youtube.com/watch?v=qmlHirOpzpc). +- Un guide sur l'intégration de Tinyauth avec Pangolin par [ivobrett](https://forum.hhf.technology/t/implementing-external-authentication-in-pangolin-using-tinyauth-and-the-middleware-manager/1417) (requiert un compte). + +:::caution + Consultez toujours la documentation officielle pour les dernières instructions de déploiement et mises à jour de configuration. +::: + +## Création d'utilisateur + +Un utilisateur Tinyauth se compose de trois éléments : un nom d'utilisateur, un hachage de mot de passe et un secret TOTP optionnel. + +```mermaid +flowchart BR + user["username:hash:totp"] + user --> username["Username in plain text"] + user --> hash["Password hashed with bcrypt"] + user --> totp["Optional TOTP secret"] +``` + +La commande CLI suivante facilite la création d'un utilisateur : + + + + ```sh + docker run -i -t --rm ghcr.io/steveiliop56/tinyauth:v5 user create --interactive + ``` + + Cette commande demande un nom d'utilisateur et un mot de passe, générant la configuration utilisateur requise. Des détails supplémentaires sont disponibles dans la référence CLI [référence](/docs/reference/cli#create-user-command). + + :::note + Lors de l'utilisation de Docker Compose ou des variables d'environnement, sélectionner l'option « format for docker » assure un échappement correct du hachage bcrypt. + ::: + + + ```sh + ./tinyauth user create --interactive + ``` + + Cette commande demande un nom d'utilisateur et un mot de passe, générant la configuration utilisateur requise. Des détails supplémentaires sont disponibles dans la référence CLI [référence](/docs/reference/cli#create-user-command). + + + + + :::note + Lors de l'utilisation de Docker Compose ou des variables d'environnement, activez l'option « Format for Docker » pour garantir un échappement correct du hachage bcrypt. + ::: + + + +Plusieurs utilisateurs peuvent être créés en répétant ce processus et en séparant les entrées par des virgules. + +## Configuration de domaine + +Tinyauth définit un cookie pour le domaine parent de l'URL de l'application. Par exemple, si l'URL de l'application est `http://tinyauth.example.com`, le cookie est défini pour `.example.com`, permettant l'authentification sur tous les sous-domaines. Voici un exemple d'une structure de domaine idéale : + +```mermaid +flowchart BR + domain["example.com"] + domain --> tinyauth["tinyauth.example.com"] + domain --> app["app.example.com"] +``` + +:::caution + L'utilisation directe avec des services DDNS (par ex. `tinyauth562.duckdns.org`) n'est pas prise en charge en raison des restrictions de cookie du navigateur. Les sous-domaines (ex. `tinyauth.mylab562.duckdns.org`) doivent être utilisés pour Tinyauth et les applications. +::: + +## Déploiement + +La configuration `docker-compose.yml` suivante déploie Tinyauth : + +```yaml title="docker-compose.yml" +tinyauth: + image: ghcr.io/steveiliop56/tinyauth:v5 + restart: unless-stopped + environment: + - TINYAUTH_APPURL=https://tinyauth.example.com + - TINYAUTH_AUTH_USERS=your-username-password-hash + labels: + traefik.enable: true + traefik.http.routers.tinyauth.rule: Host(`tinyauth.example.com`) + traefik.http.middlewares.tinyauth.forwardauth.address: http://tinyauth:3000/api/auth/traefik +``` + +Pour protéger des applications supplémentaires, incluez l'étiquette suivante dans leur configuration : + +```yaml +traefik.http.routers.[your-router].middlewares: tinyauth +``` + +Accéder à une application protégée redirige les utilisateurs vers la page de connexion Tinyauth. + +## Exemple complet + +Voici un exemple complet intégrant Traefik, Whoami et Tinyauth : + +```yaml title="docker-compose.yml" +services: + traefik: + image: traefik:v3.3 + command: --api.insecure=true --providers.docker + restart: unless-stopped + ports: + - 80:80 + volumes: + - /var/run/docker.sock:/var/run/docker.sock + + whoami: + image: traefik/whoami:latest + restart: unless-stopped + labels: + traefik.enable: true + traefik.http.routers.whoami.rule: Host(`whoami.example.com`) + traefik.http.routers.whoami.middlewares: tinyauth + + tinyauth: + image: ghcr.io/steveiliop56/tinyauth:v5 + restart: unless-stopped + environment: + - TINYAUTH_APPURL=https://tinyauth.example.com + - TINYAUTH_AUTH_USERS=user:$$2a$$10$$UdLYoJ5lgPsC0RKqYH/jMua7zIn0g9kPqWmhYayJYLaZQ/FTmH2/u # user:password + labels: + traefik.enable: true + traefik.http.routers.tinyauth.rule: Host(`tinyauth.example.com`) + traefik.http.middlewares.tinyauth.forwardauth.address: http://tinyauth:3000/api/auth/traefik +``` \ No newline at end of file diff --git a/src/content/docs/fr/docs/guides/access-controls.mdx b/src/content/docs/fr/docs/guides/access-controls.mdx new file mode 100644 index 0000000..05a3ca9 --- /dev/null +++ b/src/content/docs/fr/docs/guides/access-controls.mdx @@ -0,0 +1,200 @@ +--- +title: "Contrôles d'accès" +description: "Tinyauth prend en charge les contrôles d'accès basés sur des labels Docker." +--- + +Tinyauth prend en charge les contrôles d'accès de base avec soit des labels Docker, soit des variables d'environnement. Ces labels (ou variables d'environnement) peuvent restreindre ou autoriser l'accès aux applications. + +:::caution[Proxy configuration matters] +Tinyauth s'appuie sur l'en-tête `X-Forwarded-Host` (défini par votre reverse proxy) pour déterminer quels contrôles d'accès d'application s'appliquent à une requête donnée. Si votre proxy ne remplace pas cet en-tête, ou si tinyauth est directement accessible sur le réseau sans passer par le proxy, un utilisateur pourrait envoyer une requête avec un hôte falsifié qui ne correspond à aucune application configurée. Lorsqu'aucune application ne correspond, tinyauth considère la requête comme n'ayant aucune restriction et autorise tout utilisateur authentifié. + +Pour éviter cela, assurez-vous que votre reverse proxy définit toujours lui-même l'en-tête `X-Forwarded-Host` et ne transmet pas les valeurs fournies par le client. Traefik et Caddy font cela par défaut. Pour nginx, utilisez `proxy_set_header X-Forwarded-Host $host;` dans votre bloc de localisation. Vous devez également vous assurer que tinyauth n'est pas directement accessible depuis le réseau — seul votre reverse proxy doit pouvoir y accéder. +::: + +## Modifying the Tinyauth Container + +:::note +Vous pouvez ignorer cette étape si vous utilisez des variables d'environnement. +::: + +Pour activer les contrôles d'accès, ajoutez le volume suivant au conteneur Tinyauth : + +```yaml +services: + tinyauth: + volumes: + - /var/run/docker.sock:/var/run/docker.sock +``` + +Redémarrez Tinyauth après avoir défini le volume. + +:::note +Pour une sécurité accrue, utilisez un proxy de socket Docker comme celui de [Tecnativa](https://github.com/Tecnativa/docker-socket-proxy). Configurez Tinyauth pour utiliser le proxy en ajoutant la variable d'environnement suivante : + +```yaml +services: + tinyauth: + environment: + DOCKER_HOST: tcp://docker-socket-proxy:2375 +``` + +Assurez-vous que Tinyauth peut atteindre le conteneur du proxy de socket Docker. + +Si vous le souhaitez, vous pouvez également restreindre l'accès de Tinyauth au socket Docker en utilisant les labels suivants : + +```yaml +services: + tinyauth: + labels: + socket-proxy.allow.get: /v1\..*/(version|containers/.*|events.*)|/_ping + socket-proxy.allow.head: /_ping +``` + +*Merci à [@dombyte](https://github.com/dombyte) pour la suggestion.* +::: + +## Structure des contrôles d'accès + +Les labels de contrôle d'accès suivent cette structure : + +```yaml +tinyauth.apps.[app].[key]: [value] +``` + +De même, les variables d'environnement suivent cette structure : + +```sh +TINYAUTH_APPS_[APP]_[KEY]=[VALUE] +``` + +Où `[app]` est le nom de l'application à protéger. Cet ID d'application doit être unique pour chaque application protégée. + +## Découverte des contrôles d'accès + +Tinyauth utilise l'identifiant d'application dans les labels (ou variables d'environnement) et le sous-domaine de la requête pour faire correspondre la configuration avec l'application. Par exemple, une requête vers `app1.example.com` déclenche Tinyauth à rechercher des conteneurs avec le label `tinyauth.apps.app1.foo: bar` ou la variable d'environnement `TINYAUTH_APPS_APP1_FOO=bar`. Pour utiliser le domaine à la place, ajoutez le label suivant : + +```yaml +tinyauth.apps.myapp.config.domain: myapp.example.com +``` + +Ou la variable d'environnement suivante : + +```sh +TINYAUTH_APPS_MYAPP_CONFIG_DOMAIN=myapp.example.com +``` + +Tinyauth utilisera désormais le domaine pour faire correspondre la configuration au lieu de l'identifiant d'application. + +:::note +Les labels peuvent être définis soit sur le conteneur Tinyauth, soit sur l'application. Cependant, si vous utilisez plusieurs hôtes et que l'application s'exécute sur un hôte différent de celui de Tinyauth, les labels doivent être définis sur le conteneur Tinyauth. +::: + +:::caution +Les labels sont dynamiques et peuvent être mis à jour en temps réel, tandis que les variables d'environnement ne le sont pas et nécessitent un redémarrage de Tinyauth pour prendre effet. +::: + +## ACL Utilisateurs + +*À l'avenir, le guide utilisera le format des labels mais tout ce qui est mentionné s'applique également aux variables d'environnement.* + +Pour restreindre l'accès à des utilisateurs spécifiques, utilisez le label `users.allow` : + +```yaml +tinyauth.apps.myapp.users.allow: user1 +``` + +Seul `user1` pourra accéder à l'application. Pour bloquer des utilisateurs spécifiques, utilisez le label `users.block` : + +```yaml +tinyauth.apps.myapp.users.block: user2 +``` + +:::note +Les labels `users.allow` et `users.block` peuvent accepter une liste d'utilisateurs séparés par des virgules ou une chaîne de caractères regex (encadrée par `/`). +::: + +:::note +Ces labels s'appliquent également aux utilisateurs LDAP. +::: + +## Liste blanche OAuth + +Pour restreindre l'accès à des utilisateurs OAuth spécifiques, utilisez le label `oauth.whitelist` : + +```yaml +tinyauth.apps.myapp.oauth.whitelist: user1@example.com +``` + +Seul `user1@example.com` pourra accéder à l'application. + +:::note +Le label `oauth.whitelist` peut accepter une liste d'utilisateurs séparés par des virgules ou une chaîne de caractères regex (encadrée par `/`). +::: + +## ACL Chemins + +Pour ignorer l'authentification pour des chemins spécifiques, utilisez le label `path.allow` : + +```yaml +tinyauth.apps.myapp.path.allow: ^\/api +``` + +Pour bloquer l'accès à des chemins spécifiques, utilisez le label `path.block` : + +```yaml +tinyauth.apps.myapp.path.block: ^\/admin +``` + +:::caution +Les labels de chemin utilisent des chaînes regex. Par exemple, `^\\/api` correspond aux chemins commençant par `/api`, tandis que `^\\/ping$` correspond exactement au chemin `/ping`. +::: + +## Contrôles d'accès basés sur l'IP + +Pour autoriser l'accès basé sur les adresses IP ou les CIDR, utilisez le label `ip.allow` : + +```yaml +tinyauth.apps.myapp.ip.allow: 10.10.5.5,10.10.10.0/24 +``` + +Pour bloquer des IP spécifiques ou des sous-réseaux, utilisez le label `ip.block` : + +```yaml +tinyauth.apps.myapp.ip.block: 192.168.1.1,192.168.0.0/16 +``` + +## Contournement de l'authentification pour les IP + +Pour désactiver l'authentification pour des IP ou sous-réseaux spécifiques, utilisez le label `ip.bypass` : + +```yaml +tinyauth.apps.myapp.ip.bypass: 10.10.5.5,10.10.10.0/24 +``` + +## Contrôles d'accès utilisant les groupes OIDC + +Certains serveurs OIDC, comme Pocket ID, prennent en charge les groupes d'utilisateurs dans la réponse OIDC. Pour utiliser les groupes, assurez-vous que le champ `groups` est inclus dans la configuration du fournisseur OAuth. Ensuite, ajoutez le label `oauth.groups` : + +```yaml +tinyauth.apps.myapp.oauth.groups: admin +``` + +Seuls les utilisateurs du groupe `admin` seront autorisés à accéder à l'application. + +:::caution +Le label `oauth.groups` n'est pris en charge que pour les fournisseurs OAuth personnalisés, pas pour Google ou GitHub. +::: + +## Contrôles d'accès utilisant les groupes LDAP + +Tinyauth prend également en charge la récupération des groupes de l'utilisateur depuis le serveur LDAP et leur utilisation pour le contrôle d'accès. Pour utiliser les groupes LDAP, ajoutez le label `ldap.groups` : + +```yaml +tinyauth.apps.myapp.ldap.groups: admin +``` + +Seuls les utilisateurs du groupe `admin` seront autorisés à accéder à l'application. + +:::note +Pour des raisons de performance, les groupes LDAP ne sont pas récupérés à chaque requête. Au lieu de cela, ils sont récupérés périodiquement et mis en cache. Par défaut, le cache est rafraîchi toutes les 15 minutes. Si vous avez besoin de rafraîchir le cache plus fréquemment, vous pouvez modifier la variable d'environnement `TINYAUTH_LDAP_GROUPCACHETTL` (accepte un intervalle en secondes). +::: diff --git a/src/content/docs/fr/docs/guides/advanced.mdx b/src/content/docs/fr/docs/guides/advanced.mdx new file mode 100644 index 0000000..b96d1a8 --- /dev/null +++ b/src/content/docs/fr/docs/guides/advanced.mdx @@ -0,0 +1,108 @@ +--- +title: "Avancé" +description: "Guides et astuces pour des configurations avancées." +--- + +Vous trouverez ci-dessous quelques guides pour des configurations avancées. + +## Authentification aux applications avec Basic Auth + +Certaines applications proposent déjà des méthodes d'authentification telles que l'authentification de base (par ex., pop-ups du navigateur). Cela peut être gênant car il faut se connecter à la fois à Tinyauth et à l'application protégée. Tinyauth permet d'authentifier automatiquement les applications en ajoutant des labels d'authentification de base à l'application protégée. + +1. Pour Traefik, ajoutez le label suivant au conteneur Tinyauth : + + ```yaml + traefik.http.middlewares.tinyauth.forwardauth.authResponseHeaders: authorization + ``` + +2. Assurez-vous que Tinyauth puisse lire les labels Docker en [connectant le socket Docker au conteneur](/docs/guides/access-controls#modifying-the-tinyauth-container). + +3. Ajoutez les labels Tinyauth au service : + +```yaml +services: + whoami: + labels: + tinyauth.apps.whoami.response.basicauth.username: username + tinyauth.apps.whoami.response.basicauth.password: password +``` + +4. Redémarrez l'application. Se connecter à Tinyauth vous connectera automatiquement à l'application protégée via l'authentification de base. + +5. _(Optionnel)_ Pour renforcer la sécurité, vous pouvez utiliser les [Docker secrets](https://docs.docker.com/compose/how-tos/use-secrets) afin de stocker des secrets tels que les mots de passe dans des fichiers séparés plutôt que dans le fichier compose lui-même. Pour ce faire, créez un fichier nommé `myapp_password` contenant le mot de passe d'authentification de base et ajoutez-le en tant que secret au conteneur Tinyauth : + +```yaml +services: + tinyauth: + secrets: + - myapp_password + +secrets: + myapp_password: + file: ./myapp_password +``` + +Assurez-vous de redémarrer le conteneur Tinyauth après avoir ajouté le secret. Puis modifiez les labels de l'application pour lire le mot de passe depuis le secret : + +```yaml +services: + whoami: + labels: + tinyauth.apps.whoami.response.basicauth.username: username + tinyauth.apps.whoami.response.basicauth.passwordFile: /run/secrets/myapp_password +``` + +## Réseau hôte et Traefik + +Lors de l'utilisation de `network_mode: host` dans Docker en parallèle avec Traefik, le `redirect_uri` dans Tinyauth par défaut pointe vers l'URL de l'application au lieu du véritable URI de redirection. Cela se produit parce que Traefik ne respecte pas l'en-tête `X-Forwarded-Host` provenant d'adresses IP NAT comme celles internes à Docker. Cela peut être résolu en : + +- En utilisant la configuration Traefik suivante : + +```yaml +entryPoints: + web: + forwardedHeaders: + trustedIPs: + - 127.0.0.1/32 + - 172.16.0.0/12 +``` + +- Ou en utilisant des arguments CLI : + +```sh +--entryPoints.web.forwardedHeaders.trustedIPs=127.0.0.1/32,172.16.0.0/12 +``` + +_Voir le problème [#35](https://github.com/steveiliop56/tinyauth/issues/35) par [Aleksey](https://github.com/liveder)._ + +## Tinyauth derrière un proxy + +Dans certains environnements, Tinyauth peut avoir besoin de fonctionner derrière un autre proxy. Par exemple, Tinyauth pourrait être hébergé sur `tinyauth.mydomain.com` tandis que son middleware est utilisé par un autre proxy à l'adresse `http://tinyauth.mydomain.com/api/auth/traefik`. + +Dans de tels cas, Traefik ne respecte pas les en-têtes `X-Forwarded-*`, ce qui fait que le `redirect_uri` dans Tinyauth pointe vers le domaine de Tinyauth au lieu du domaine de l'application. Pour corriger cela, configurez Traefik pour faire confiance aux en-têtes provenant du proxy en amont. Par exemple : + +```mermaid +flowchart LR + user["User"] --> tinyauthExposed["tinyauth.mydomain.com"] + tinyauthExposed --> proxy1["Proxy 1 (10.0.0.2)"] + proxy1 --> proxy2["Proxy 2 (10.0.0.3)"] + proxy2 --> tinyauth["Tinyauth"] +``` + +Configurez Proxy 1 pour faire confiance aux en-têtes de Proxy 2 : + +```yaml +entryPoints: + web: + forwardedHeaders: + trustedIPs: + - 10.0.0.2 +``` + +Alternativement, utilisez des options CLI : + +```sh +--entryPoints.web.forwardedHeaders.trustedIPs=10.0.0.2 +``` + +_Voir le problème [#134](https://github.com/steveiliop56/tinyauth/issues/134#issuecomment-2848793841) par [@eliasbenb](https://github.com/eliasbenb)._ diff --git a/src/content/docs/fr/docs/guides/github-app-oauth.mdx b/src/content/docs/fr/docs/guides/github-app-oauth.mdx new file mode 100644 index 0000000..ca14903 --- /dev/null +++ b/src/content/docs/fr/docs/guides/github-app-oauth.mdx @@ -0,0 +1,65 @@ +--- +title: "OAuth des Applications GitHub" +description: "Utilisez l'écran OAuth des Applications GitHub pour vous authentifier auprès de Tinyauth." +--- + +Tinyauth prend en charge les Applications GitHub pour l'authentification au lieu des Applications OAuth. Les Applications GitHub offrent un meilleur contrôle sur les autorisations et sont légèrement plus complexes à configurer. Pour des configurations plus simples, [Applications OAuth](/docs/guides/github-oauth) sont recommandées. + +## Exigences + +GitHub requiert les éléments suivants pour configurer une application : + +- Un nom de domaine (les non-gTLD sont pris en charge) +- Un compte GitHub + +## Création de l'Application GitHub + +Ouvrez le site des [Applications GitHub](https://github.com/settings/apps) et cliquez sur **Nouvelle Application GitHub**. + +Ensuite, remplissez les informations suivantes : + +| Nom | Valeur | +| --------------- | ------------------------------------------------------------------------------------------------------------------------------ | +| Nom de l'application GitHub | Le nom de l'application, par ex., `Tinyauth`. | +| URL de la page d'accueil | Toute URL, par ex., `https://tinyauth.app`. | +| URL de rappel | L'URL de l'application Tinyauth suivie de `/api/oauth/callback/github`, par ex., `https://tinyauth.example.com/api/oauth/callback/github`. | + +![Écran de création d'application GitHub](/screenshots/github/app-new.png) + +Sous le webhook, assurez-vous que la case à cocher **Actif** est décochée car les webhooks ne sont pas requis. + +Dans la section **Autorisations**, cliquez sur **Autorisation du compte** et définissez l'option **Adresses e-mail** sur **Lecture seule** : + +![Section des e-mails GitHub](/screenshots/github/app-email.png) + +Enfin, créez l'application. L'écran suivant apparaîtra : + +![Page d'accueil de l'Application GitHub](/screenshots/github/app-home.png) + +Remarquez le client ID. Pour générer le secret du client, cliquez sur **Générer un nouveau secret de client**. Après l'authentification, le secret apparaîtra : + +![Secret du client GitHub](/screenshots/github/app-secret.png) + +Enregistrez le client ID et le secret car ils seront nécessaires pour Tinyauth. + +## Configuration de Tinyauth + +Ajoutez les variables d'environnement suivantes au conteneur Docker Tinyauth : + +```yaml +services: + tinyauth: + environment: + - TINYAUTH_OAUTH_PROVIDERS_GITHUB_CLIENTID=your-github-client-id + - TINYAUTH_OAUTH_PROVIDERS_GITHUB_CLIENTSECRET=your-github-secret +``` + +:::caution + OAuth seul ne garantit pas la sécurité. Par défaut, tout compte GitHub peut se connecter en tant qu'utilisateur normal. Pour restreindre l'accès, utilisez la variable d'environnement `TINYAUTH_OAUTH_WHITELIST` pour autoriser des adresses e-mail spécifiques. Reportez-vous à la page [configuration](/docs/reference/configuration) pour plus de détails. +::: + +:::note + Avec l'authentification OAuth activée, la variable d'environnement `TINYAUTH_AUTH_USERS` ou `TINYAUTH_AUTH_USERSFILE` peut être supprimée pour autoriser uniquement la connexion via le fournisseur OAuth. +::: + +Redémarrez Tinyauth. En visitant l'écran de connexion, une option supplémentaire pour se connecter avec GitHub apparaîtra. \ No newline at end of file diff --git a/src/content/docs/fr/docs/guides/github-oauth.mdx b/src/content/docs/fr/docs/guides/github-oauth.mdx new file mode 100644 index 0000000..8f0a396 --- /dev/null +++ b/src/content/docs/fr/docs/guides/github-oauth.mdx @@ -0,0 +1,63 @@ +--- +title: "OAuth GitHub" +description: "Utilisez OAuth GitHub pour l'authentification à Tinyauth." +--- + +Tinyauth prend en charge OAuth GitHub avec seulement deux variables d'environnement. La plupart de la configuration se fait côté GitHub plutôt que sur Tinyauth. + +## Requirements + +- Un nom de domaine (les non-gTLD sont pris en charge) +- Un compte GitHub + +## Creating the GitHub OAuth App + +Commencez par créer une application OAuth GitHub. Accédez aux [paramètres développeur GitHub](https://github.com/settings/developers) et cliquez sur **Nouvelle application OAuth**. Remplissez les détails suivants : + +| Nom | Valeur | +| -------------------------- | -------------------------------------------------------------------------------------------------------------------------- | +| Nom de l'application | Peut être n'importe quoi, par ex., `Tinyauth`. | +| URL de la page d'accueil | Peut être n'importe quelle URL, par ex., `https://tinyauth.app`. | +| URL de rappel d'autorisation | Entrez le domaine suivi de `/api/oauth/callback/github`, par ex., `https://tinyauth.example.com/api/oauth/callback/github`. | + +![GitHub new OAuth app](/screenshots/github/oauth-new.png) + +Après avoir entré les détails, cliquez sur **Enregistrer l'application**. + +## Retrieving Credentials + +Une fois l'application créée, l'écran suivant apparaîtra : + +![GitHub OAuth app homepage](/screenshots/github/oauth-home.png) + +Prenez note de l'ID client. Pour générer le secret client, cliquez sur **Générer un nouveau secret client**. GitHub demandera une confirmation de connexion puis affichera le secret : + +![GitHub OAuth Client Secret](/screenshots/github/oauth-secret.png) + +Prenez note de l'ID client et du secret pour une utilisation ultérieure. + +## Configuring Tinyauth + +Add the following environment variables to the Tinyauth Docker container: + +```yaml +services: + tinyauth: + environment: + - TINYAUTH_OAUTH_PROVIDERS_GITHUB_CLIENTID=your-github-client-id + - TINYAUTH_OAUTH_PROVIDERS_GITHUB_CLIENTSECRET=your-github-secret +``` + +:::caution +OAuth seul ne garantit pas la sécurité. Par défaut, tout compte GitHub peut +se connecter en tant qu'utilisateur normal. Pour restreindre l'accès, utilisez la variable d'environnement `TINYAUTH_OAUTH_WHITELIST` +pour autoriser des adresses e-mail spécifiques. Reportez-vous à la page +[configuration](/docs/reference/configuration) pour plus de détails. +::: + +:::note +Avec OAuth activé, la variable d'environnement `TINYAUTH_AUTH_USERS` ou `TINYAUTH_AUTH_USERSFILE` peut être +supprimée pour autoriser uniquement la connexion via le fournisseur OAuth. +::: + +Redémarrez Tinyauth. Lors de la visite de l'écran de connexion, une option supplémentaire pour se connecter avec GitHub apparaîtra. \ No newline at end of file diff --git a/src/content/docs/fr/docs/guides/google-oauth.mdx b/src/content/docs/fr/docs/guides/google-oauth.mdx new file mode 100644 index 0000000..b3ac51b --- /dev/null +++ b/src/content/docs/fr/docs/guides/google-oauth.mdx @@ -0,0 +1,76 @@ +--- +title: "OAuth Google" +description: "Utilisez l'écran OAuth de Google pour vous authentifier à Tinyauth." +--- + +Tinyauth prend en charge l'OAuth de Google, ce qui facilite sa configuration. + +## Requirements + +- Un nom de domaine (gTLD requis) +- Un compte Google + +## Creating the Google OAuth App + +Pour commencer, créez une application dans la [Google Cloud Console](https://console.cloud.google.com). Créez un nouveau projet (un projet par défaut peut déjà exister). Après avoir créé le projet, l'écran suivant devrait apparaître : + +![Google Cloud Console Home](/screenshots/google/cloud-home.png) + +Depuis le menu d'accès rapide, cliquez sur **APIs & Services**, puis sélectionnez **OAuth consent screen** dans la barre latérale. Cliquez sur le bouton **Get Started** au centre de l'écran. + +:::note + Google a mis à jour la section OAuth. Ce guide utilise la nouvelle expérience OAuth. Si un bouton apparaît indiquant « Try the new OAuth experience », cliquez dessus pour suivre les étapes de ce guide. +::: + +Après avoir cliqué sur le bouton, l'écran suivant devrait apparaître : + +![Configure OAuth Consent Screen](/screenshots/google/oauth-configure.png) + +- **App Name**: Utilisez `Tinyauth`. +- **Support Email**: Sélectionnez l'adresse e-mail disponible. +- **Audience**: Choisissez **External**. +- **Contact Information**: Entrez une adresse e-mail. +- Acceptez la politique d'utilisation des données et cliquez sur **Create**. + +Après quelques instants, la page d'accueil OAuth apparaîtra : + +![Google Cloud OAuth Home](/screenshots/google/oauth-home.png) + +Cliquez sur **Create OAuth Client**. + +:::note + Il est possible qu'un avertissement apparaisse concernant l'écran de consentement OAuth non configuré. Dans ce cas, attendez quelques minutes et actualisez la page. +::: + +- **Application Type**: Sélectionnez **Web Application**. +- **Name**: Renommez éventuellement le client (par défaut c'est `Web Client 1`). +- **Authorized Redirect URIs**: Ajoutez le domaine avec le suffixe `/api/oauth/callback/google`, par ex. `https://tinyauth.example.com/api/oauth/callback/google`. + +Cliquez sur **Create**. Une fois l'application créée, l'écran suivant apparaîtra : + +![Google Cloud OAuth Clients](/screenshots/google/client-created.png) + +Cliquez sur le client (par ex. `Web Client 1`) et copiez l'ID client et le secret client depuis la section Informations supplémentaires. + +## Configuring Tinyauth + +Add the following environment variables to the Tinyauth Docker container: + +```yaml +services: + tinyauth: + environment: + - TINYAUTH_OAUTH_PROVIDERS_GOOGLE_CLIENTID=your-google-client-id + - TINYAUTH_OAUTH_PROVIDERS_GOOGLE_CLIENTSECRET=your-google-secret +``` + +:::caution + OAuth seul ne garantit pas la sécurité. Par défaut, tout compte Google peut se connecter en tant qu'utilisateur normal. Pour restreindre l'accès, utilisez la variable d'environnement `TINYAUTH_OAUTH_WHITELIST` pour autoriser des adresses e-mail spécifiques. Reportez-vous à la page [configuration](/docs/reference/configuration) pour plus de détails. +::: + +:::note + Avec l'OAuth activé, la variable d'environnement `TINYAUTH_AUTH_USERS` ou `TINYAUTH_AUTH_USERSFILE` peut être supprimée pour autoriser uniquement la connexion via le fournisseur OAuth. +::: + + +Redémarrez Tinyauth. En visitant l'écran de connexion, une option supplémentaire pour se connecter avec Google apparaîtra. \ No newline at end of file diff --git a/src/content/docs/fr/docs/guides/ldap.mdx b/src/content/docs/fr/docs/guides/ldap.mdx new file mode 100644 index 0000000..defe733 --- /dev/null +++ b/src/content/docs/fr/docs/guides/ldap.mdx @@ -0,0 +1,86 @@ +--- +title: "Serveur LDAP" +description: "Utilisez un serveur LDAP centralisé pour la gestion des utilisateurs dans Tinyauth." +--- + +LDAP, while often associated with businesses, can be highly effective for centralizing user management in a homelab environment. Tinyauth supports LDAP as a user source, making it easier to manage users across applications. + +## Exigences + +Un serveur LDAP est requis pour poursuivre. [LLDAP](https://github.com/lldap/lldap) est recommandé pour son design léger et sa facilité de configuration. Ce guide utilise LLDAP, mais tout serveur LDAP est compatible. + +## Création d'utilisateurs + +Tinyauth nécessite au moins deux utilisateurs : un utilisateur observateur avec accès en lecture seule à la base de données (utilisé par Tinyauth pour rechercher les DN des utilisateurs) et un utilisateur normal pour se connecter à Tinyauth et aux applications. + +### Création de l'utilisateur observateur + +1. Accédez à l'onglet **Users** dans LLDAP et cliquez sur **Create a user**. +2. Fournissez un nom d'utilisateur, un mot de passe et une adresse e-mail, puis cliquez sur **Submit**. + +![LLDAP Create a User](/screenshots/lldap/new-user.png) + +3. Après avoir créé l'utilisateur, sélectionnez-le dans la liste et faites défiler jusqu'à la section des appartenances aux groupes. Ajoutez l'utilisateur au groupe `lldap_strict_readonly` en cliquant sur **Add to Group**. + +![LLDAP Groups](/screenshots/lldap/user-groups.png) + +### Création d'utilisateurs supplémentaires + +Répétez le processus pour créer des utilisateurs supplémentaires. Les utilisateurs normaux n'ont pas besoin de appartenir à un groupe. + +## Configuration de Tinyauth + +Pour connecter Tinyauth au serveur LDAP, ajoutez les variables d'environnement suivantes au conteneur Docker de Tinyauth : + +```yaml +services: + tinyauth: + environment: + - TINYAUTH_LDAP_ADDRESS=ldap://my-lldap-server:3890 + - TINYAUTH_LDAP_BINDDN=uid=your-observer-user,ou=people,dc=example,dc=com + - TINYAUTH_LDAP_BINDPASSWORD=your-observer-user-password + - TINYAUTH_LDAP_BASEDN=dc=example,dc=com + - TINYAUTH_LDAP_SEARCHFILTER=(uid=%s) + - TINYAUTH_LDAP_INSECURE=true +``` + +:::note + Le filtre de recherche peut être personnalisé selon les besoins. Le filtre de base `(uid=%s)` recherche les utilisateurs en fonction de leur UID, avec `%s` remplacé par le nom d'utilisateur du compte tentant de se connecter. +::: + +:::note + Remplacez le bind DN et le base DN par des valeurs spécifiques à la configuration du serveur LDAP. +::: + +Après avoir redémarré, il devrait être possible de se connecter à Tinyauth avec le deuxième utilisateur créé dans LLDAP. Des utilisateurs supplémentaires peuvent être créés et utilisés pour la connexion selon les besoins. + +:::note + Les utilisateurs LDAP sont traités de la même manière que les utilisateurs provenant de fichiers ou de variables d'environnement. Il n'y a aucune indication dans l'interface utilisateur qu'un utilisateur est connecté via LDAP. Tous les contrôles d'accès s'appliquent également aux utilisateurs LDAP et aux utilisateurs standard. +::: + +## Utilisation des groupes LDAP pour le contrôle d'accès + +Tinyauth prend en charge l'extraction des informations de groupe depuis le fournisseur LDAP. Cela vous permet de configurer les groupes d'application directement à partir du serveur LDAP. Les groupes sont extraits en utilisant le filtre `(&(objectclass=groupOfUniqueNames)(uniquemember=%s))` où `%s` est remplacé par le nom d'utilisateur du compte tentant de se connecter. Ce filtre devrait fonctionner avec la plupart des serveurs LDAP. + +:::warning + Les groupes LDAP ne sont pas actualisés à chaque requête pour des raisons de performance. Au lieu de cela, ils sont mis en cache pendant une courte période afin de minimiser le nombre de requêtes vers le serveur LDAP. La durée du cache peut être configurée via la variable d'environnement `TINYAUTH_LDAP_GROUPCACHETTL`. La durée par défaut est de 900 secondes (15 minutes). +::: + +Après avoir créé un groupe dans LLDAP : + +![LLDAP Create Group](/screenshots/lldap/new-group.png) + +Vous pouvez ensuite attribuer des utilisateurs au groupe : + +![LLDAP Assign User to Group](/screenshots/lldap/user-assign-group.png) + +Enfin, utilisez le [LDAP Group ACL](/docs/guides/access-controls/#access-controls-using-ldap-groups) pour autoriser uniquement les utilisateurs du groupe `admins` dans votre application : + +```yaml +services: + foo: + labels: + tinyauth.apps.foo.ldap.groups: admins +``` + +Si un utilisateur LDAP n'est pas membre du groupe `admins`, il ne se verra pas accorder l'accès à l'application et sera redirigé vers une page non autorisée. \ No newline at end of file diff --git a/src/content/docs/fr/docs/guides/nginx-proxy-manager.mdx b/src/content/docs/fr/docs/guides/nginx-proxy-manager.mdx new file mode 100644 index 0000000..12002e9 --- /dev/null +++ b/src/content/docs/fr/docs/guides/nginx-proxy-manager.mdx @@ -0,0 +1,115 @@ +--- +title: "Gestionnaire de proxy Nginx" +description: "Utilisez Tinyauth avec le proxy inverse Nginx Proxy Manager." +--- + +Nginx Proxy Manager est un outil populaire dans la communauté homelab pour gérer les proxys inverses. Bien qu'il diffère de Traefik et Caddy en raison du manque de prise en charge native des redirections 302 dans le module `auth_request` d'Nginx, Tinyauth fournit des chemins API spécifiquement conçus pour fonctionner avec celui-ci. + +:::note + Ce guide suppose une familiarité avec Nginx Proxy Manager. +::: + +## Exemple de fichier Docker Compose + +Le fichier Docker Compose suivant démontre comment configurer Nginx Proxy Manager, Whoami et Tinyauth : + +```yaml title="docker-compose.yml" +services: + npm: + image: jc21/nginx-proxy-manager:2 + restart: unless-stopped + ports: + - 80:80 + - 443:443 + - 81:81 + volumes: + - npm-data:/data + - npm-letsencrypt:/etc/letsencrypt + + # Whoami is not required, but serves as a simple example app to demonstrate Tinyauth integration. You can replace it with any app of your choice. + whoami: + image: traefik/whoami:latest + restart: unless-stopped + + tinyauth: + image: ghcr.io/steveiliop56/tinyauth:v5 + restart: unless-stopped + environment: + - TINYAUTH_APPURL=http://tinyauth.example.com + - TINYAUTH_AUTH_USERS=user:$$2a$$10$$UdLYoJ5lgPsC0RKqYH/jMua7zIn0g9kPqWmhYayJYLaZQ/FTmH2/u # user:password + +volumes: + npm-data: + npm-letsencrypt: +``` + +Les contrôles d'accès OAuth peuvent être configurés à l'aide des étiquettes Docker et des variables d'environnement. Toutes les autres configurations sont gérées via l'interface utilisateur du Gestionnaire de proxy Nginx. + +## Configuration du Gestionnaire de proxy Nginx + +### Création de l'hôte Tinyauth + +Créez un hôte pour Tinyauth dans le Gestionnaire de proxy Nginx. Configurez-le comme tout autre hôte : + +![Créer l'hôte Tinyauth](/screenshots/npm/tinyauth-host.png) + +SSL peut être configuré si des certificats sont disponibles. + +:::caution + Assurez-vous que l'option "Block Common Exploits" est désactivée. Si activé, Nginx bloquera les URL dans les paramètres de requête, ce qui est requis pour le fonctionnement de Tinyauth. +::: + +### Configurer les hôtes protégés + +Pour les hôtes protégés, tels que Whoami, configurez l'onglet Détails de la même manière que pour l'hôte Tinyauth : + +![Créer l'hôte Whoami](/screenshots/npm/whoami-host.png) + +SSL peut être configuré selon les besoins. + +:::note + L'option "Block Common Exploits" peut rester activée pour les hôtes protégés. +::: + +### Configuration avancée + +Ajoutez la configuration suivante dans l'onglet Avancé pour activer l'authentification Tinyauth : + +```sh +# Root location +location / { + # Pass the request to the app + proxy_pass http://whoami:80; # Replace with your app URL, e.g. http://10.10.10.25:80 + + # Add other app-specific config here + + # Tinyauth auth request + auth_request /tinyauth; + auth_request_set $redirection_url $upstream_http_x_tinyauth_location; + error_page 401 403 =302 $redirection_url; +} + +# Tinyauth auth request +location /tinyauth { + # Mark the location as internal to prevent direct access + internal; + + # Pass request to Tinyauth, do not use the Tinyauth domain here, use the internal Docker network name and port or the IP and port of the Tinyauth instance + proxy_pass http://tinyauth:3000/api/auth/nginx; + + # Pass the request headers + proxy_set_header x-forwarded-proto $scheme; + proxy_set_header x-forwarded-host $http_host; + proxy_set_header x-forwarded-uri $request_uri; +} +``` + +:::note + Le chemin `/tinyauth` peut être renommé pour plus de commodité. +::: + +:::note + Une configuration supplémentaire peut être requise sous l'emplacement `/` pour les technologies comme WebSockets. +::: + +Enregistrez la configuration de l'hôte. Accéder à l'hôte protégé redirigera vers la page de connexion Tinyauth si vous n'êtes pas déjà connecté. Répétez ce processus pour chaque hôte à protéger par Tinyauth. \ No newline at end of file diff --git a/src/content/docs/fr/docs/guides/oidc.mdx b/src/content/docs/fr/docs/guides/oidc.mdx new file mode 100644 index 0000000..9e88787 --- /dev/null +++ b/src/content/docs/fr/docs/guides/oidc.mdx @@ -0,0 +1,167 @@ +--- +title: "Serveur OIDC" +description: "Utilisez le serveur OIDC de Tinyauth pour authentifier les applications." +--- + +import { Tabs, TabItem } from '@astrojs/starlight/components'; +import CreateOidcClientTool from "../../../../../components/create-oidc-client-tool.astro"; + +Dans Tinyauth v5, une étape majeure fut l'introduction du serveur OIDC, qui permet à Tinyauth non seulement d'utiliser d'autres fournisseurs d'identité mais aussi de fonctionner comme un fournisseur d'identité lui-même. Cela signifie que Tinyauth peut servir de passerelle d'authentification centrale pour plusieurs applications, offrant une expérience de connexion unique aux utilisateurs. + +## Qu'est-ce qu'OpenID Connect? + +From [https://openid.net](https://openid.net/developers/discover-openid-and-openid-connect/): + +> OpenID est une façon simple et sécurisée pour les personnes de réutiliser un compte existant et le profil utilisateur d'un fournisseur d'identité, par exemple Apple, Google ou Microsoft, afin de se connecter à toute application ou site Web compatible OpenID sans créer une nouvelle inscription ni mot de passe. Vous choisissez le fournisseur, tel que Google, puis entrez votre adresse Gmail et votre mot de passe pour vous connecter. + +## Limites + +Tinyauth implémente les parties Core et Discovery du protocole OpenID Connect. + +![OpenID Connect Protocol Suite](https://openid.net/wp-content/uploads/2023/06/OpenIDConnect-Map-December2023.png) + +Avant d'utiliser Tinyauth comme serveur OIDC, veuillez vous assurer que l'implémentation répond à vos exigences. + +Types de réponse pris en charge : + +- `code` + +Types d'octroi d'autorisation pris en charge : + +- `authorization_code` +- `refresh_token` + +Scopes pris en charge : + +- `openid` +- `profile` +- `email` +- `groups` + +Claims pris en charge : + +- `sub` +- `name` +- `email` +- `preferred_username` +- `groups` +- `updated_at` +- `email_verified` + +Méthodes d'authentification du point de terminaison de jeton prises en charge : + +- `client_secret_basic` +- `client_secret_post` + +En raison de la nature *presque* sans état de Tinyauth, le champ `sub` de l'utilisateur est basé sur l'ID client et le nom d'utilisateur. Cela signifie que si le nom d'utilisateur ou l'ID client change, le `sub` changera également. Cela peut entraîner des problèmes avec certains clients OIDC qui se fient à la revendication `sub` pour identifier l'utilisateur de manière cohérente. + +:::note +Bien qu'aucune promesse ne puisse être faite, si vous pensez qu'une fonctionnalité requise d'OpenID Connect manque, veuillez ouvrir un problème sur [GitHub](https://github.com/steveiliop56/tinyauth/issues). +::: + +## Considérations importantes + +L'idée principale de Tinyauth est d'être une application sans état, mais OIDC nécessite une persistance pour la session et le stockage des clés. Tout est stocké dans le répertoire `/data`, donc si vous utilisez Docker, ajoutez le volume correspondant à votre fichier `docker-compose.yml` : + +```yaml +services: + tinyauth: + volumes: + - ./data:/data +``` + +Si vous utilisez le binaire, vous pouvez spécifier le répertoire de la base de données en utilisant la variable d'environnement `TINYAUTH_DATABASE_PATH` ou l'option CLI `--database.path`. + +Vous devez également spécifier les chemins où sont stockées les clés publiques et privées. Cela peut être fait avec `TINYAUTH_OIDC_PRIVATEKEYPATH` (`--oidc.privatekeypath`) et `TINYAUTH_OIDC_PUBLICKEYPATH` (`--oidc.publickeypath`) respectivement. + +Enfin, pour que le serveur OIDC fonctionne, HTTPS est **obligatoire** sur l'URL de l'application, qui deviendra l'URL d'émetteur. Vous pouvez utiliser un certificat auto-signé ou un certificat provenant d'une autorité de certification (CA) de confiance. + +## Création de clients OIDC + +Pour créer un client OIDC, utilisez la commande `oidc create`. Par exemple : + + + + ```sh + docker run -i -t --rm ghcr.io/steveiliop56/tinyauth:v5 oidc create myapp + ``` + + Cela produira une sortie similaire à : + + ``` + Client Name: myapp + Client ID: client-id + Client Secret: ta-client-secret + ``` + + + ```sh + ./tinyauth oidc create myapp + ``` + + Cela produira une sortie similaire à : + + ``` + Client Name: myapp + Client ID: client-id + Client Secret: ta-client-secret + ``` + + + + + + +Nous utiliserons ces valeurs pour le reste de ce guide, alors assurez-vous de les garder sécurisées. + +:::caution +Le nom du client doit être unique et ne contenir que des caractères alphanumériques et des tirets. +::: + +Vous pouvez répéter ce processus pour autant de clients que vous le souhaitez. + +## Configuration de Tinyauth + +Chaque client OIDC doit être configuré avec les variables d'environnement suivantes (en utilisant les valeurs de l'étape précédente) : + +```sh +TINYAUTH_OIDC_CLIENTS_MYAPP_CLIENTID=client-id +TINYAUTH_OIDC_CLIENTS_MYAPP_CLIENTSECRET=ta-client-secret +TINYAUTH_OIDC_CLIENTS_MYAPP_TRUSTEDREDIRECTURIS=https://example.com/callback +TINYAUTH_OIDC_CLIENTS_MYAPP_NAME=myapp +``` + +Ou avec la série suivante d'options CLI : + +```sh +--oidc.clients.myapp.clientid=client-id +--oidc.clients.myapp.clientsecret=ta-client-secret +--oidc.clients.myapp.trustedredirecturis=https://example.com/callback +--oidc.clients.myapp.name=myapp +``` + +:::note +Si vous préférez, vous pouvez utiliser `TINYAUTH_OIDC_CLIENTS_[NAME]_CLIENTSECRETFILE` (`--oidc.clients.[name].clientsecretfile`) pour spécifier le chemin où est stocké le secret du client. +::: + +## Configuration de l'application + +Tinyauth expose un chemin bien connu à `/.well-known/openid-configuration` que les applications peuvent utiliser pour découvrir automatiquement la configuration du serveur OIDC. Si votre application ne prend pas en charge la découverte, vous pouvez le configurer avec les points de terminaison suivants : + +| Nom | URL | +| --------------------- | ---------------------------------------------------- | +| Point de terminaison d'autorisation | `https://tinyauth.example.com/authorize` | +| Point de terminaison du jeton | `https://tinyauth.example.com/api/oidc/token` | +| Point de terminaison des informations utilisateur | `https://tinyauth.example.com/api/oidc/userinfo` | + +## Utilisation + +Une fois tout configuré, démarrez Tinyauth et accédez à votre application. Après avoir sélectionné Tinyauth comme source d'authentification, vous devriez être redirigé vers Tinyauth, où vous pourrez vous connecter et autoriser l'application. + +![Tinyauth Authorize Screen](/screenshots/oidc/authorize.png) + +:::note +Tinyauth conservera la requête OIDC lors de la connexion. Les utilisateurs se connectant via des fournisseurs OAuth seront automatiquement redirigés vers la page d'autorisation après une authentification réussie. +::: + +Tinyauth transmettra les informations utilisateur provenant du fournisseur OIDC ou LDAP à l'application tout en agissant comme un proxy. Profitez-en ! \ No newline at end of file diff --git a/src/content/docs/fr/docs/guides/other-oauth.mdx b/src/content/docs/fr/docs/guides/other-oauth.mdx new file mode 100644 index 0000000..5300a5d --- /dev/null +++ b/src/content/docs/fr/docs/guides/other-oauth.mdx @@ -0,0 +1,67 @@ +--- +title: "Autres fournisseurs OAuth" +description: "Utilisez n'importe quel fournisseur OAuth avec Tinyauth." +--- + +Tinyauth prend en charge tout fournisseur OAuth/OpenID Connect qui respecte la spécification (en particulier concernant les revendications). Cela signifie que vous pouvez utiliser n'importe quel fournisseur auto-hébergé ou tiers qui implémente les protocoles OAuth 2.0 et/ou OpenID Connect. + +## Exigences + +- Une instance Tinyauth configurée et en cours d'exécution. +- Un fournisseur OAuth/OpenID Connect que vous souhaitez intégrer à Tinyauth. Il peut s'agir d'un fournisseur auto-hébergé comme Keycloak ou d'un fournisseur tiers tel qu'Auth0, Okta, ou tout autre qui prend en charge OAuth 2.0/OpenID Connect. + +## Obtenez vos identifiants client + +Pour intégrer votre fournisseur OAuth à Tinyauth, vous devrez créer un client/application dans le tableau de bord de votre fournisseur OAuth. Ce processus varie selon le fournisseur que vous utilisez, mais implique généralement les étapes suivantes : + +1. Connectez-vous au tableau de bord de votre fournisseur OAuth. +2. Accédez à la section où vous pouvez créer un nouveau client/application. +3. Remplissez les informations requises, telles que le nom de votre application et l'URI de redirection. L'URI de redirection doit être au format `https://your-tinyauth-instance.com/api/oauth/callback/your-provider`, où `your-provider` est un identifiant unique pour votre fournisseur OAuth (par ex., `keycloak`, `auth0`, etc.). +4. Enregistrez le client/l'application et notez l'ID client ainsi que le secret client, car vous en aurez besoin pour configurer Tinyauth. + +Vous devrez également obtenir les URL des points de terminaison d'autorisation, de jeton et d'information utilisateur auprès de votre fournisseur OAuth. Ces URLs sont généralement disponibles dans la documentation du fournisseur, le tableau de bord ou via leur point de découverte OpenID Connect (généralement trouvé à `https://your-provider/.well-known/openid-configuration`). + +## Configurer Tinyauth + +Une fois que vous avez vos identifiants client et les URL des points de terminaison, vous pouvez configurer Tinyauth pour utiliser votre fournisseur OAuth. Cela implique d'ajouter une nouvelle configuration de fournisseur à votre instance. Vous pouvez le faire en ajoutant les variables d'environnement suivantes à votre configuration Tinyauth : + +```yaml +services: + tinyauth: + environment: + - TINYAUTH_OAUTH_PROVIDERS_MYPROVIDER_CLIENTID=your-provider-client-id + - TINYAUTH_OAUTH_PROVIDERS_MYPROVIDER_CLIENTSECRET=your-provider-client-secret + - TINYAUTH_OAUTH_PROVIDERS_MYPROVIDER_AUTHURL=your-provider-authorization-endpoint + - TINYAUTH_OAUTH_PROVIDERS_MYPROVIDER_TOKENURL=your-provider-token-endpoint + - TINYAUTH_OAUTH_PROVIDERS_MYPROVIDER_USERINFOURL=your-provider-userinfo-endpoint + - TINYAUTH_OAUTH_PROVIDERS_MYPROVIDER_REDIRECTURL=https://your-tinyauth-instance.com/api/oauth/callback/myprovider # This is usually not needed as Tinyauth can auto-generate it, but you can specify it if your provider requires a specific redirect URL. + - TINYAUTH_OAUTH_PROVIDERS_MYPROVIDER_SCOPES="openid email profile groups" # Ensure you include the necessary scopes for your provider. + - TINYAUTH_OAUTH_PROVIDERS_MYPROVIDER_NAME="My Provider" # This is the name that will be displayed on the login page for this provider. + - TINYAUTH_OAUTH_PROVIDERS_MYPROVIDER_INSECURE=false # Only set this to true if your provider uses self-signed certificates +``` + +Assurez-vous de remplacer `MYPROVIDER` par un identifiant unique pour votre fournisseur et d'entrer les valeurs correctes pour l'ID client, le secret client et les URL des points de terminaison. + +:::caution +L'identifiant du fournisseur (par ex., `MYPROVIDER`) doit être unique et ne contenir que des caractères alphanumériques. Cet identifiant est utilisé dans l'URI de redirection et les noms de variables d'environnement, choisissez donc judicieusement. +::: + +Vous pouvez ajouter plusieurs fournisseurs en répétant la configuration ci-dessus avec différents identifiants (par ex., `KEYCLOAK`, `AUTH0`, etc.). + +## Astuces et avertissements + +:::note + Définissez la variable d'environnement `TINYAUTH_OAUTH_AUTOREDIRECT` sur l'ID de votre fournisseur (par ex., `myprovider`) pour activer le redirection automatique vers votre fournisseur OAuth pour les applications protégées par Tinyauth. +::: + +:::caution + OAuth seul ne garantit pas la sécurité. Par défaut, tout compte dans le fournisseur OAuth peut se connecter en tant qu'utilisateur normal. Pour restreindre l'accès, utilisez la variable d'environnement `TINYAUTH_OAUTH_WHITELIST` pour autoriser des adresses e-mail spécifiques. Reportez-vous à la page [configuration](/docs/reference/configuration) pour plus de détails. +::: + +:::note + Avec OAuth activé, la variable d'environnement `TINYAUTH_AUTH_USERS` ou `TINYAUTH_AUTH_USERSFILE` peut être supprimée pour autoriser uniquement la connexion via le fournisseur OAuth. +::: + +## Essayez-le + +Après avoir configuré Tinyauth, redémarrez votre instance pour appliquer les modifications. Vous devriez maintenant voir une option de connexion avec votre fournisseur OAuth sur la page d'accueil. Cliquez dessus et vous serez redirigé vers votre fournisseur OAuth pour vous authentifier. Après l'authentification, vous serez redirigé à nouveau vers Tinyauth et devriez être connecté avec succès. \ No newline at end of file diff --git a/src/content/docs/fr/docs/guides/pocket-id.mdx b/src/content/docs/fr/docs/guides/pocket-id.mdx new file mode 100644 index 0000000..a365452 --- /dev/null +++ b/src/content/docs/fr/docs/guides/pocket-id.mdx @@ -0,0 +1,91 @@ +--- +title: "OAuth Pocket ID" +description: "Utilisez Pocket ID comme fournisseur OAuth dans Tinyauth." +--- + +[Pocket ID](https://pocket-id.org) est un serveur OIDC populaire qui permet la connexion aux applications avec des passkeys. La plupart des proxys ne prennent pas en charge les serveurs OIDC/OAuth pour l'authentification, ce qui signifie que Pocket ID ne peut pas être utilisé avec eux. Avec Tinyauth, Pocket ID peut être intégré aux proxys pour sécuriser les applications. + +## Requirements + +Une installation fonctionnelle de Pocket ID est requise. Reportez‑vous à la [documentation](https://pocket-id.org/docs/setup/installation) de Pocket ID pour les instructions d'installation. + +## Configuring Pocket ID + +Commencez par accéder au tableau de bord d'administration de Pocket ID : + +![Page d’administration Pocket ID](/screenshots/pocketid/home.png) + +Naviguez vers l’onglet **Clients OIDC** (sous **Administration**) et cliquez sur **Ajouter un client OIDC**. Fournissez les informations suivantes : + +| Nom | Valeur | +| ------------- | ------------------------------------------------------------------- | +| Nom | Attribuez un nom au client, par ex. `Tinyauth`. | +| URLs de rappel | Entrez l’URL de l’application Tinyauth suivie de `/api/oauth/callback/pocketid`. Par exemple : `https://tinyauth.example.com/api/oauth/callback/pocketid`. | + +![Création d’un client Pocket ID](/screenshots/pocketid/new-client.png) + +Vous pouvez également télécharger un logo pour le client OIDC. Le logo de Tinyauth est disponible sur [GitHub](https://github.com/steveiliop56/tinyauth/blob/main/assets/logo.png). + +Cliquez sur **Enregistrer**. Une nouvelle page affichera les informations d’identification OIDC : + +![Page client Pocket ID](/screenshots/pocketid/client-page.png) + +Notez l’ID client et le secret pour une utilisation ultérieure. + +## Configuring Tinyauth + +Pour intégrer Tinyauth à Pocket ID, ajoutez les variables d’environnement suivantes au conteneur Docker de Tinyauth : + +```yaml +services: + tinyauth: + environment: + - TINYAUTH_OAUTH_PROVIDERS_POCKETID_CLIENTID=your-pocket-id-client-id + - TINYAUTH_OAUTH_PROVIDERS_POCKETID_CLIENTSECRET=your-pocket-id-client-secret + - TINYAUTH_OAUTH_PROVIDERS_POCKETID_AUTHURL=https://pocket-id.example.com/authorize + - TINYAUTH_OAUTH_PROVIDERS_POCKETID_TOKENURL=https://pocket-id.example.com/api/oidc/token + - TINYAUTH_OAUTH_PROVIDERS_POCKETID_USERINFOURL=https://pocket-id.example.com/api/oidc/userinfo + - TINYAUTH_OAUTH_PROVIDERS_POCKETID_REDIRECTURL=https://tinyauth.example.com/api/oauth/callback/pocketid + - TINYAUTH_OAUTH_PROVIDERS_POCKETID_SCOPES=openid email profile groups + - TINYAUTH_OAUTH_PROVIDERS_POCKETID_NAME=Pocket ID +``` + +:::note +Pocket ID doit être accessible via HTTPS et un certificat de confiance. Si ce n’est pas possible (par ex. certificats auto‑signés), vous devrez utiliser `TINYAUTH_OAUTH_PROVIDERS_POCKETID_INSECURE=true` afin que Tinyauth ignore la vérification du certificat. +::: + +:::note +Définissez la variable d’environnement `TINYAUTH_OAUTH_AUTOREDIRECT` sur `pocketid` pour activer la redirection automatique vers Pocket ID pour les applications protégées par Tinyauth. +::: + +:::caution +OAuth seul ne garantit pas la sécurité. Par défaut, tout compte Pocket ID peut se connecter en tant qu’utilisateur normal. Pour restreindre l’accès, utilisez la variable d’environnement `TINYAUTH_OAUTH_WHITELIST` pour autoriser des adresses e‑mail spécifiques. Reportez‑vous à la page [configuration](/docs/reference/configuration) pour plus de détails. +::: + +:::note +Avec OAuth activé, les variables d’environnement `TINYAUTH_AUTH_USERS` ou `TINYAUTH_AUTH_USERSFILE` peuvent être supprimées pour autoriser uniquement la connexion via le fournisseur OAuth. +::: + +Redémarrez Tinyauth pour appliquer les modifications. L’écran de connexion inclura désormais une option pour se connecter avec Pocket ID. + +## Access Controls with Pocket ID Groups + +Pocket ID prend en charge les groupes d’utilisateurs, ce qui peut simplifier la gestion du contrôle d’accès. Pour utiliser des groupes, créez‑en un en naviguant vers l’onglet **Groupes d’utilisateurs** et en cliquant sur **Ajouter un groupe**. Attribuez un nom et enregistrez le groupe : + +![Nouveau groupe Pocket ID](/screenshots/pocketid/new-group.png) + +Sélectionnez les utilisateurs à inclure dans le groupe : + +![Page d’accueil du groupe Pocket ID](/screenshots/pocketid/group-home.png) + +Configurez les applications protégées par Tinyauth pour exiger des groupes OAuth en ajoutant l’étiquette `oauth.groups` : + +```yaml +tinyauth.apps.myapp.oauth.groups: admins +``` + +Dans cet exemple, seuls les utilisateurs Pocket ID du groupe `admins` peuvent accéder à l’application. Les utilisateurs hors du groupe seront redirigés vers une page non autorisée. + +:::caution +Par défaut, Tinyauth utilise le nom de sous‑domaine de la requête pour trouver un conteneur correspondant aux étiquettes. Par exemple, une requête vers `myapp.example.com` vérifie les étiquettes dans le conteneur nommé `myapp`. Ce comportement peut être modifié en utilisant le label `tinyauth.apps.[app].config.domain`. Reportez‑vous au guide [contrôles d’accès](/docs/guides/access-controls#access-controls-discovery) pour plus d’informations. +::: \ No newline at end of file diff --git a/src/content/docs/fr/docs/guides/runtipi.mdx b/src/content/docs/fr/docs/guides/runtipi.mdx new file mode 100644 index 0000000..cb55433 --- /dev/null +++ b/src/content/docs/fr/docs/guides/runtipi.mdx @@ -0,0 +1,51 @@ +--- +title: "Runtipi" +description: "Utilisez Tinyauth avec la plateforme de gestion du serveur domestique Runtipi." +--- + +Runtipi est un assistant de serveur domestique personnel open-source conçu pour gérer et exécuter plusieurs services sur un seul serveur. Pour plus de détails, visitez le [site officiel](https://runtipi.io). Grâce à ses fonctionnalités proxy robustes, Runtipi s'intègre parfaitement avec Tinyauth pour offrir une expérience d'authentification fluide. + +## Création d'utilisateurs et de clients OAuth + +Les utilisateurs peuvent être créés en utilisant le [CLI](/docs/reference/cli#create-user-command) de Tinyauth. Assurez-vous que l'option format for docker est sélectionnée pour permettre à Tinyauth d'analyser correctement l'utilisateur. + +L'application Runtipi inclut des champs pour GitHub et Google OAuth. Pour utiliser OAuth, reportez-vous aux guides OAuth et prenez note des identifiants clients et des secrets. + +## Modification du middleware d'authentification directe + +Par défaut, Runtipi utilise son propre écran de connexion pour l'authentification. Pour le remplacer par Tinyauth, activez les paramètres avancés : + +![Activer les paramètres avancés](/screenshots/runtipi/advanced-settings-enable.png) + +Définissez l'URL d'authentification directe à : + +``` +http://tinyauth:3000/api/auth/traefik +``` + +![Définir l'URL d'authentification directe](/screenshots/runtipi/forward-auth-url.png) + +Enregistrez les paramètres et redémarrez Runtipi. + +:::note + Depuis la version v4 de Runtipi, le support de plusieurs magasins d'applications a été ajouté. Cela peut modifier le nom du conteneur. Si la redirection vers l'écran de connexion Tinyauth échoue, utilisez : + `http://tinyauth_migrated-tinyauth-1:3000/api/auth/traefik` comme URL d'authentification directe (en supposant que vous installez Tinyauth depuis le magasin officiel). +::: + +## Installation de Tinyauth + +Accédez à l'onglet Appstore, sélectionnez l'application Tinyauth et remplissez les champs utilisateurs, les identifiants OAuth et les autres informations requises. Avant l'installation, activez soit le commutateur de domaine local, soit celui d'exposition pour garantir que Tinyauth est accessible via un domaine. Cela est nécessaire pour une gestion correcte des cookies. En fonction de la configuration, utilisez soit le domaine local, soit le domaine exposé comme URL de l'application (assurez-vous d'utiliser HTTPS). Enfin, complétez le processus d'installation. + +:::note + Des options de personnalisation supplémentaires, telles que l'ajout de plus de fournisseurs OAuth, sont disponibles via le [user-config](https://runtipi.io/docs/guides/customize-app-config) de Runtipi. +::: + +## Activation de l'authentification pour les applications + +L'authentification peut être activée pour toute application en ouvrant ses paramètres et en basculant le commutateur d'activation de l'authentification : + +![Activer l'authentification pour l'application](/screenshots/runtipi/app-auth-enable.png) + +:::caution + Pour que l'authentification fonctionne correctement, assurez-vous que le domaine local ou exposé partage le même domaine de niveau racine que Tinyauth. Par exemple, `tinyauth.example.com` et `nginx.example.com` fonctionneront, mais `tinyauth.domain1.com` et `nginx.domain2.com` ne fonctionneront pas. +::: \ No newline at end of file diff --git a/src/content/docs/fr/docs/guides/totp.mdx b/src/content/docs/fr/docs/guides/totp.mdx new file mode 100644 index 0000000..1d48cc9 --- /dev/null +++ b/src/content/docs/fr/docs/guides/totp.mdx @@ -0,0 +1,62 @@ +--- +title: "Authentification à deux facteurs" +description: "Utilisez TOTP pour ajouter une couche supplémentaire de sécurité à vos comptes." +--- + +import { Tabs, TabItem } from '@astrojs/starlight/components'; +import GenerateTotpTool from "../../../../../components/generate-totp-tool.astro"; + +Tinyauth prend en charge TOTP en natif, permettant l'utilisation d'applications d'authentification pour générer des codes 2FA lors de la connexion. + +## Génération du secret + +Un secret TOTP doit d'abord être généré. Cela nécessite le `username:hash` actuel. Utilisez l'interface en ligne de commande Tinyauth pour créer le nouvel utilisateur : + + + + ```sh + docker run -i -t --rm ghcr.io/steveiliop56/tinyauth:v5 totp generate --interactive + ``` + + La commande demande l'utilisateur et génère un code QR à scanner avec une application d'authentification. Une fois ajouté, copiez le nouvel utilisateur généré (affiché après le message de log `user=`) et incluez-le dans la liste des utilisateurs Tinyauth. Redémarrez Tinyauth pour appliquer les modifications. + + :::note + En raison du fonctionnement de la bibliothèque de codes QR dans Tinyauth, le code QR peut être **énorme** et ne pas tenir sur un écran standard. Si cela se produit, vous pouvez essayer de redimensionner votre fenêtre de terminal ou d'utiliser un émulateur de terminal différent. + ::: + + + ```sh + ./tinyauth totp generate --interactive + ``` + + La commande demande l'utilisateur et génère un code QR à scanner avec une application d'authentification. Une fois ajouté, copiez le nouvel utilisateur généré (affiché après le message de log `user=`) et incluez-le dans la liste des utilisateurs Tinyauth. Redémarrez Tinyauth pour appliquer les modifications. + + :::note + En raison du fonctionnement de la bibliothèque de codes QR dans Tinyauth, le code QR peut être **énorme** et ne pas tenir sur un écran standard. Si cela se produit, vous pouvez essayer de redimensionner votre fenêtre de terminal ou d'utiliser un émulateur de terminal différent. + ::: + + + + + Copiez la chaîne d'utilisateur mise à jour et incluez-la dans la liste des utilisateurs Tinyauth. Redémarrez Tinyauth pour appliquer les modifications. À partir de ce moment, la connexion nécessitera un code TOTP. + + + +## Vérification de l'utilisateur + +Si vous souhaitez vérifier que l'utilisateur est correctement configuré, vous pouvez utiliser la commande suivante : + + + + ```sh + docker run -i -t --rm ghcr.io/steveiliop56/tinyauth:v5 user verify --interactive + ``` + + + ```sh + ./tinyauth user verify --interactive + ``` + + + +La commande demande le `username:hash:totp`, l'utilisateur, le mot de passe et un code TOTP provenant de l'application d'authentification. En cas de succès, un message indiquant que l'utilisateur est vérifié s'affiche. \ No newline at end of file diff --git a/src/content/docs/fr/docs/guides/using-the-binary.mdx b/src/content/docs/fr/docs/guides/using-the-binary.mdx new file mode 100644 index 0000000..5e06e47 --- /dev/null +++ b/src/content/docs/fr/docs/guides/using-the-binary.mdx @@ -0,0 +1,109 @@ +--- +title: "Utilisation du binaire" +description: "Utilisez le binaire Tinyauth au lieu de l'image Docker pour des configurations plus avancées." +--- + +Pour les configurations qui ne nécessitent pas Docker, le binaire Tinyauth offre une alternative légère. Cette approche est idéale pour les conteneurs LXC ou les machines où Docker n'est pas nécessaire mais où Tinyauth reste requis pour protéger les services. + +## Téléchargement du binaire + +Le binaire peut être téléchargé depuis la [dernière version GitHub](https://github.com/steveiliop56/tinyauth/releases/latest). Des builds sont disponibles pour les machines Linux `arm64` et `amd64`. Renommer le binaire en `tinyauth` est recommandé pour assurer une cohérence tout au long de ce guide. Assurez-vous que le binaire est exécutable : + +```sh +chmod +x tinyauth +``` + +## Configuration + +La configuration peut être réalisée en utilisant soit des drapeaux CLI, soit des variables d'environnement (recommandé). Pour utiliser les variables d'environnement, téléchargez le fichier exemple `.env` depuis GitHub : + +```sh +curl -o .env https://raw.githubusercontent.com/steveiliop56/tinyauth/refs/heads/main/.env.example +``` + +:::note +Il est recommandé d'utiliser une balise lors du téléchargement du fichier exemple `.env` afin de vous assurer que vous utilisez la dernière version stable et non une version de développement. Par exemple : + +```sh +curl -o .env https://raw.githubusercontent.com/steveiliop56/tinyauth/refs/tags/v5.0.0/.env.example +``` + +Téléchargera le fichier exemple `.env` pour la balise `v5.0.0`. +::: + +Modifiez le fichier `.env` pour remplacer les valeurs modèles par des valeurs réelles ou supprimez celles qui ne sont pas nécessaires. Alternativement, vous pouvez utiliser des drapeaux CLI pour la configuration, bien que cette méthode soit moins recommandée en raison de la complexité potentielle et des problèmes d'analyse du shell. Utilisez toujours des guillemets (`'`) afin de garantir que les valeurs soient transmises correctement. + +Une liste complète des variables d'environnement et des drapeaux CLI est disponible sur la page [configuration](/docs/reference/configuration). + +## Exécution + +Une fois configuré, démarrez Tinyauth. Pour les configurations basées sur des variables d'environnement, exportez les variables dans le shell : + +```sh +export $(grep -v '^#' .env | xargs -d '\n') +``` + +:::note + Pour désactiver les variables d'environnement à des fins de sécurité, utilisez : `unset $(grep + -v '^#' .env | sed -E 's/(.*)=.*/\1/' | xargs)`. +::: + +Démarrez le serveur Tinyauth : + +```sh +./tinyauth +``` + +Pour les configurations basées sur des drapeaux CLI, passez directement les drapeaux : + +```sh +./tinyauth --appurl=https://tinyauth.example.com +``` + +## Exécution en tant que service systemd + +Pour activer le démarrage automatique de Tinyauth au démarrage, créez un service systemd. Tout d'abord, créez le fichier de service : + +```ini title="/etc/systemd/system/tinyauth.service" +[Unit] +Description=Tinyauth service +After=network.target + +[Service] +EnvironmentFile=/some/path/.env +ExecStart=/some/path/tinyauth +Restart=on-failure + +[Install] +WantedBy=multi-user.target +``` + +:::note + Remplacez les chemins dans le fichier de service par les emplacements réels des fichiers d'environnement + et du binaire. +::: + +:::note + Pour les configurations basées sur des drapeaux CLI, supprimez la ligne `EnvironmentFile` et ajoutez les drapeaux à la ligne `ExecStart`, par exemple : `ExecStart=/some/path/tinyauth + --appurl=https://tinyauth.example.com`. +::: + +Rechargez le démon systemd : + +```sh +sudo systemctl daemon-reload +``` + +Activez et démarrez le service : + +```sh +sudo systemctl enable --now tinyauth +``` + +Les journaux peuvent être consultés avec : + +```sh +sudo journalctl -efu tinyauth +``` + +Tinyauth démarrera désormais automatiquement au démarrage. \ No newline at end of file diff --git a/src/content/docs/fr/docs/integrations/zerobyte.mdx b/src/content/docs/fr/docs/integrations/zerobyte.mdx new file mode 100644 index 0000000..e487e2a --- /dev/null +++ b/src/content/docs/fr/docs/integrations/zerobyte.mdx @@ -0,0 +1,82 @@ +--- +title: "Zerobyte" +description: "Utilisez le fournisseur OpenID Connect Tinyauth pour authentifier les utilisateurs avec Zerobyte." +--- + +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +[Zerobyte](https://github.com/nicotsx/zerobyte) est une solution d'automatisation de sauvegarde auto-hébergée populaire basée sur restic. Elle permet aux utilisateurs de gérer et automatiser facilement leurs tâches de sauvegarde via une interface web conviviale. En intégrant Tinyauth comme fournisseur OpenID Connect, vous pouvez renforcer la sécurité de votre instance Zerobyte en activant l'authentification unique (SSO) et centralisée. + +## Exigences + +- Une instance de Zerobyte en cours d'exécution +- Une instance de Tinyauth +- Une tasse de café (facultatif mais recommandé) + +:::caution +Vous devrez exécuter Tinyauth avec HTTPS pour l'utiliser comme fournisseur OpenID Connect. +::: + +## Configuration de Tinyauth + +Pour commencer, nous devons générer un identifiant client et un secret dans Tinyauth pour Zerobyte. Cela peut être fait en exécutant la commande suivante : + + + + ```sh + docker run -i -t --rm ghcr.io/steveiliop56/tinyauth:v5 oidc create zerobyte + ``` + + + ```sh + ./tinyauth oidc create zerobyte + ``` + + + +À partir de la sortie, assurez-vous d'enregistrer l'identifiant client et le secret car nous en aurons besoin plus tard pour la configuration de Zerobyte. + +Ensuite, nous pouvons transmettre notre configuration à Tinyauth via des variables d'environnement : + +```sh +TINYAUTH_OIDC_PRIVATEKEYPATH=/path/to/private/key.pem +TINYAUTH_OIDC_PUBLICKEYPATH=/path/to/public/key.pem +TINYAUTH_OIDC_CLIENTS_ZEROBYTE_CLIENTID=client-id +TINYAUTH_OIDC_CLIENTS_ZEROBYTE_CLIENTSECRET=ta-client-secret +TINYAUTH_OIDC_CLIENTS_ZEROBYTE_TRUSTEDREDIRECTURIS=https://your-zerobyte-instance.com/api/auth/sso/callback/tinyauth +TINYAUTH_OIDC_CLIENTS_ZEROBYTE_NAME=Zerobyte +``` + +:::note +Dans le champ des URI de redirection approuvées, nous avons utilisé le suffixe `/tinyauth` pour l'URL de rappel. Cela doit correspondre au nom du client que nous créerons dans Zerobyte à l'étape suivante. Si vous souhaitez utiliser un nom différent, assurez-vous de mettre à jour l'URL de rappel en conséquence. +::: + +Redémarrez votre instance Tinyauth pour appliquer la nouvelle configuration. + +## Configuration de Zerobyte + +Ensuite, nous devons configurer Zerobyte pour utiliser Tinyauth comme fournisseur OpenID Connect. Cela peut être fait en créant un nouveau client dans le panneau d'administration de Zerobyte. Vous pouvez naviguer vers la page *Settings* puis l'onglet *Organization*. Ici, vous pouvez cliquer sur *Register New* sous la section *Single Sign-On* pour créer un nouveau client. + +Remplissez le formulaire avec les détails suivants : + +| Nom | Valeur | +| - | - | +| Provider ID | `tinyauth` | +| Organization Domain | Le domaine parent de votre instance Tinyauth, par ex., `example.com` | +| Issuer URL | L'URL d'émetteur de votre instance Tinyauth, par ex., `https://tinyauth.example.com` | +| Discovery Endpoint | Le point de terminaison de découverte suivi de `/.well-known/openid-configuration`, par ex., `https://tinyauth.example.com/.well-known/openid-configuration` | +| Client ID | L'identifiant client généré à l'étape précédente. | +| Client Secret | Le secret client généré à l'étape précédente. | +| Link matching emails to existing accounts | Lier les e-mails correspondants aux comptes existants (facultatif, mais vous voudrez probablement activer cette option si vos utilisateurs ont les mêmes adresses e-mail dans Tinyauth et Zerobyte.) | + +![Zerobyte Create Client Preview](/screenshots/zerobyte/create-client.png) + +Après avoir rempli le formulaire, cliquez sur le bouton *Register Provider* pour créer le nouveau client. Enfin, si votre adresse e‑mail Tinyauth ne correspond à aucun des utilisateurs existants de Zerobyte, vous devrez les inviter à votre instance. + +Vous pouvez le faire en naviguant vers la section *Invite-only access*, en entrant l'adresse e‑mail de l'utilisateur que vous souhaitez inviter, en sélectionnant le rôle approprié, puis en cliquant sur le bouton *Invite*. + +![Zerobyte Invite User Preview](/screenshots/zerobyte/invite-user.png) + +Enfin, vous pouvez tester l'intégration en vous déconnectant de votre instance Zerobyte puis en cliquant sur le bouton *Login with Tinyauth* sur la page de connexion. Vous devriez être redirigé vers la page de connexion Tinyauth, où vous pourrez entrer vos identifiants pour vous authentifier. Après une authentification réussie, vous serez redirigé vers Zerobyte et connecté à votre compte. + +![Zerobyte Login Preview](/screenshots/zerobyte/login.png) \ No newline at end of file diff --git a/src/content/docs/fr/docs/reference/authentication.mdx b/src/content/docs/fr/docs/reference/authentication.mdx new file mode 100644 index 0000000..970afc8 --- /dev/null +++ b/src/content/docs/fr/docs/reference/authentication.mdx @@ -0,0 +1,46 @@ +--- +title: "Authentification" +description: "Méthodes d'authentification prises en charge par Tinyauth." +--- + +Tinyauth prend en charge plusieurs méthodes d'authentification, vous permettant de choisir celle qui convient le mieux à vos besoins. Vous trouverez ci-dessous un aperçu des méthodes d'authentification disponibles. + +## Nom d'utilisateur et mot de passe + +Tinyauth prend en charge l'authentification à l'aide d'un nom d'utilisateur et d'un mot de passe. Le mot de passe est haché de manière sécurisée avec bcrypt, garantissant qu'il est stocké en toute sécurité. Vous pouvez créer des utilisateurs au format `username:hash`, où `hash` est le hash bcrypt du mot de passe. + +Il est également possible d'inclure un secret TOTP optionnel pour l'authentification à deux facteurs. La configuration utilisateur peut être représentée comme suit : + +```mermaid +flowchart BR + user["username:hash:totp"] + user --> username["Username in plain text"] + user --> hash["Password hashed with bcrypt"] + user --> totp["Optional TOTP secret"] +``` + +## Authentification de base + +Par défaut, Tinyauth permet l'authentification en utilisant l'en-tête `Authorization` avec le schéma Basic. Cela signifie que les clients peuvent envoyer des identifiants au format `username:password` encodés en Base64, que Tinyauth décodera et vérifiera par rapport à la configuration utilisateur stockée. + +:::caution + Lors de l'utilisation de l'authentification de base, les comptes utilisant TOTP ne pourront pas s'authentifier, car le code TOTP ne peut pas être fourni dans l'en-tête `Authorization`. Pour les comptes avec TOTP activé, envisagez d'utiliser une authentification basée sur des cookies. +::: + +## Authentification LDAP + +Tinyauth prend également en charge l'authentification LDAP, vous permettant d'intégrer des annuaires LDAP existants pour la gestion des utilisateurs. Cela vous permet de tirer parti de votre base d'utilisateurs et de vos mécanismes d'authentification existants sans avoir besoin de créer des comptes séparés pour Tinyauth. + +## Authentification OpenID Connect + +Tinyauth peut être configuré pour utiliser OpenID Connect à des fins d'authentification, permettant aux utilisateurs de s'authentifier en utilisant leurs comptes existants auprès de fournisseurs tels que Google, GitHub ou tout autre service conforme à OpenID Connect. Cela offre un moyen pratique et sécurisé pour les utilisateurs d'accéder à votre application sans avoir besoin de gérer des identifiants séparés. + +L'implémentation OpenID dans Tinyauth exige que le fournisseur OpenID prenne en charge au minimum les portées `openid`, `profile` et `email`, car elles sont nécessaires pour récupérer les informations utilisateur et garantir une expérience d'authentification fluide. Les portées non obligatoires utilisées par Tinyauth incluent `prefered_username`, `name` et `groups`, qui peuvent fournir des informations supplémentaires sur l'utilisateur si le fournisseur les prend en charge. Si le fournisseur OpenID ne prend pas en charge les portées requises, l'authentification échouera et les utilisateurs ne pourront pas accéder à l'application via OpenID Connect. + +:::note + Tinyauth propose des préréglages pour certains fournisseurs OpenID populaires, simplifiant le processus de configuration. Si vous pensez qu'un préréglage pour un fournisseur OpenID serait utile, veuillez soumettre une demande ou contribuer un préréglage au projet. +::: + +:::caution + Microsoft OAuth n'est ***pas*** pris en charge par Tinyauth en raison de son non-conformité à la norme OpenID Connect, qui est une exigence pour l'implémentation OpenID Connect de Tinyauth. Microsoft OAuth ne fournit pas les portées et les informations utilisateur nécessaires au bon fonctionnement de Tinyauth, entraînant des échecs d'authentification lorsqu'on tente d'utiliser Microsoft OAuth comme méthode d'authentification. Pour plus d'informations, consultez [#26](https://github.com/steveiliop56/tinyauth/issues/26#issuecomment-3897779709). +::: \ No newline at end of file diff --git a/src/content/docs/fr/docs/reference/changelog.mdx b/src/content/docs/fr/docs/reference/changelog.mdx new file mode 100644 index 0000000..26e166a --- /dev/null +++ b/src/content/docs/fr/docs/reference/changelog.mdx @@ -0,0 +1,626 @@ +--- +title: "Changelog" +description: "Vue d'ensemble des changements et mises à jour dans les versions de Tinyauth." +--- + +## v5.0.7 + +### Améliorations + +- Le serveur OpenID Connect prend désormais en charge PKCE +- L'endpoint d'information utilisateur OpenID Connect prend désormais en charge les requêtes POST @scottmckendry +- L'endpoint d'information utilisateur OpenID Connect accepte désormais le jeton d'accès dans le corps de la requête POST @scottmckendry +- Le flux OAuth prend désormais en charge les paramètres OpenID Connect et stocke les états CSRF côté serveur pour prévenir la falsification +- Ajout du header `X-Tinyauth-Location` pour les instances Nginx afin de rediriger automatiquement vers les pages de connexion et d'accès non autorisé +- Prise en charge des objets de requête OpenID Connect sans signature @scottmckendry +- Améliorations d'accessibilité + +### Corrections + +- Utiliser les redirections 307 pour le proxy Envoy +- Corriger le remplissage automatique du champ TOTP qui ne fonctionnait pas dans certains gestionnaires de mots de passe @scottmckendr + +### Technique + +- Mise à jour des dépendances +- Mise à jour des traductions +- Utiliser notre propre fork de la bibliothèque [paerser](https://github.com/tinyauthapp/paerser) pour une meilleure flexibilité dans l'analyse des configurations +- Échec précoce de l'application lorsque l'URL de l'app est manquante + +## v5.0.6 + +### Corrections + +- Corriger le fonctionnement incorrect de la détection du navigateur pour certains proxys + +### Technique + +- Mise à jour des dépendances + +## v5.0.5 + +:::caution +Cette version contient une correction de sécurité, veuillez mettre à jour dès que possible. +::: + +:::note +Pour les utilisateurs d'Envoy/Istio, vous devrez peut-être inclure `user-agent` dans votre configuration `includeRequestHeadersInCheck` pour que la détection du navigateur fonctionne. +::: + +### Améliorations + +- OAuth prend désormais en charge plusieurs tentatives de connexion simultanées +- Amélioration de la détection du navigateur basée sur l'en-tête `User-Agent` +- Support amélioré des proxys avec de nouveaux modules spécifiques aux proxys +- Limitation automatique du débit pour toute l'instance en cas de multiples tentatives de connexion +- Autoriser les domaines au niveau racine comme URL d'app à des fins de test +- Tenter d'extraire le contexte uniquement sur les routes qui en ont besoin + +### Corrections + +- Correction du contrôleur proxy ne récupérant pas les informations de requête depuis les déploiements Nginx + +### Technique + +- Mise à jour des dépendances +- Mise à jour des traductions +- Correction du mauvais tag utilisé pour les métadonnées dans le flux de travail de publication @jacekkow +- Refactorisation des tests du contrôleur pour un test beaucoup plus complet, robuste et extensible + +## v5.0.4 + +### Améliorations + +- Prise en charge de l'en-tête `X-Original-URI` + +### Corrections + +- `X-Forwarded-URI` ne doit pas être requis + +### Technique + +- Mise à jour des dépendances + +## v5.0.3 + +:::caution +Cette version contient des corrections de sécurité, veuillez mettre à jour dès que possible. +::: + +### Corrections + +- Ne pas poursuivre l'authentification sur les en-têtes `X-Forwarded-*` vides. +- S'assurer que l'utilisateur est connecté et n'est pas dans le flux 2FA à l'endpoint d'autorisation +- Vérifier que l'identifiant client correspond à l'entrée de code avant d'émettre un jeton + +### Technique + +- Mise à jour des dépendances +- Mise à jour des traductions + +## v5.0.2 + +### Améliorations + +- Prise en charge des clés publiques PKIX [@DarkDare](https://github.com/DarkDare) + +### Corrections + +- Ajout de `kid` dans l'en-tête JWT du jeton d'identité +- Rendre le champ état non obligatoire dans la requête d'autorisation +- Accepter le port et l'adresse individuellement dans la commande `healthcheck` [@luizfelipefb](https://github.com/luizfelipefb) + +### Technique + +- Mise à jour des dépendances + +## v5.0.1 + +### Corrections + +- S'assurer que `kid` est présent dans la réponse JWKS +- Gérer le nom de client vide sur la page d'autorisation +- Utiliser la bonne variable d'environnement et l'indicateur pour le chargement de configuration +- Vérifier que le nonce est reconnu dans la réponse du jeton d'identité +- S'assurer que `email_verified` est présent comme revendication dans le jeton d'identité et la réponse des informations utilisateur +- S'assurer que les en-têtes de contrôle du cache sont définis sur l'endpoint de jeton + +### Technique + +- Mise à jour des dépendances +- Mise à jour des traductions + +## v5.0.0 + +:::caution +Il s'agit d'une version majeure, veuillez consulter la [documentation](/docs/breaking-updates/4-to-5) pour les instructions de migration. +::: + +### Nouvelles fonctionnalités + +- Prise en charge expérimentale du fichier de configuration +- Ajout du support pour le proxy Envoy [@pushpinderbal](https://github.com/pushpinderbal) +- Rafraîchir le cookie de session tant que la session est active +- Transférer la revendication `sub` des fournisseurs OAuth dans l'en-tête `Remote-Sub` +- Prise en charge des ACL via variables d'environnement / indicateurs CLI / fichier de configuration +- Ajout du support d'authentification mTLS / certificat client dans LDAP [@plaes](https://github.com/plaes) +- Ajout du support des filtres IP globaux +- Journalisation configurable au niveau du composant [@pushpinderbal](https://github.com/pushpinderbal) +- ACL de groupe LDAP +- Soumission automatique du code TOTP lorsqu'il est saisi +- Serveur OIDC + +### Améliorations + +- Créer automatiquement le répertoire de base de données s'il n'existe pas [@modrin](https://github.com/modrin) +- Utiliser un format de configuration unique pour les variables d'environnement, indicateurs CLI et fichier de configuration +- Améliorer la performance du front-end en minimisant les appels use-effect et la taille des morceaux [@nicotsx](https://github.com/nicotsx) + +### Corrections + +- Correction de la détection de langue stockant un code incorrect dans le stockage local +- Ajout d'une limitation du débit dans l'endpoint d'authentification directe pour prévenir les attaques par force brute utilisant l'authentification basique [@offw0rld](https://github.com/offw0rld) +- Masquer le fournisseur d'utilisateur lorsqu'aucun utilisateur n'est configuré [@pushpinderbal](https://github.com/pushpinderbal) +- Définir le mode Gin dans le code plutôt que via des variables d'environnement +- S'assurer que la vérification de redirection sécurisée prend en compte les points + +### Technique + +- Mise à jour des dépendances +- Mise à jour des traductions +- Correction de [CVE-2025-55182](https://github.com/advisories/GHSA-fv66-9v8q-g76r "CVE-2025-55182") dans React [@d3vv3](https://github.com/d3vv3) +- Diviser le démarrage de l'app en tâches plus petites pour une meilleure lisibilité et maintenabilité +- Utiliser le nom de module correct – Tinyauth est désormais listé dans [pkg.go.dev](https://pkg.go.dev/github.com/steveiliop56/tinyauth) +- Remplacer GORM par SQL vanilla et SQLC pour une taille plus petite et un code plus maintenable +- Ajouter un `Makefile` pour simplifier le développement +- Simplifier la logique d'analyse des utilisateurs car nous pouvons déléguer les choses à paerser + +## v4.1.0 + +### Nouvelles fonctionnalités + +- Mode clair +- Prise en charge de l'écoute sur des sockets UNIX +- Journaliser les nouvelles sessions dans `TRACE` +- Prise en charge de la journalisation en JSON +- Ajouter une option pour désactiver les avertissements UI + +### Améliorations + +- Générer un vérificateur OAuth à chaque tentative de connexion +- Ajout d'une routine de nettoyage des sessions expirées +- Journaliser l'URI de redirection non sécurisée dans le contrôleur OAuth + +### Corrections + +- S'assurer que les fournisseurs OAuth ont le préfixe `PROVIDERS_` +- Autoriser tous les sous-domaines à être considérés sûrs pour les redirections + +### Technique + +- Utiliser les génériques Gorm pour toutes les opérations de base de données +- Essayer de nettoyer la logique des décodeurs +- Accélérer le flux de travail de développement air en ne pas installer delve à chaque rechargement +- Mise à jour des dépendances +- Mise à jour des traductions + +## v4.0.1 + +:::caution +Cette version contient une correction de sécurité concernant la découverte d'étiquettes, veuillez mettre à jour dès que possible. +::: + +### Améliorations + +- Déplacer la vérification de connexion Docker au démarrage afin que la découverte d'étiquettes puisse échouer en cas de plantage du proxy socket +- Utiliser le module de récupération GIN pour traduire les panic en erreurs 500 +- Trier les fournisseurs OAuth par longueur de nom +- Autoriser les redirections vers le domaine du cookie racine +- Utiliser une journalisation plus verbeuse pour le niveau de log `trace` + +### Corrections + +- S'assurer que le répertoire de données existe sur les images Docker +- Supprimer les espaces de fin avant de vérifier le nom d'utilisateur et le nom OAuth +- Ne pas utiliser le nom du conteneur pour la découverte d'étiquettes + +### Technique + +- Utiliser les variantes meta Docker pour les images +- Mise à jour des dépendances + +## v4.0.0 + +:::caution +Il s'agit d'une version majeure, veuillez suivre le guide de migration dans la [documentation](/docs/breaking-updates/3-to-4). +::: + +### Nouvelles fonctionnalités + +- Base de données SQLite pour stocker les sessions +- Avertissement dans l'UI lorsque le domaine actuel ne correspond pas à celui configuré +- Option de configuration des proxys de confiance (`TRUSTED_PROXIES`/`--trusted-proxies`) +- Serveur de fichiers vous permettant de servir des ressources statiques comme l'image d'arrière-plan (`RESOURCES_DIR`/`--resources-dir`) +- Substitution Dash pour le slash dans les étiquettes IP permettant l'utilisation du CIDR dans Kubernetes +- S'assurer que l'URL de l'app n'est pas dans la liste des suffixes publics afin d'éviter les problèmes de cookies +- Plusieurs fournisseurs OAuth +- Diagramme [Helm](https://helm.tinyauth.app) pour les déploiements Kubernetes +- Commande de vérification d'état + +### Améliorations + +- Les étiquettes d'app ont été refondues pour permettre une configuration ACL plus propre +- Flux d'auto-redirection OAuth amélioré pour une redirection plus fluide +- L'écran de continuation a été refactorisé en un gestionnaire de redirection supprimant le besoin de cliquer sur des boutons supplémentaires +- Mise au point automatique du formulaire TOTP +- Définir le titre de la page à l'aide de la variable d'environnement `APP_TITLE` +- Ajouter un cache dans le front-end pour des temps de chargement plus rapides + +### Corrections + +- Désactiver l'indexation dans l'écran de connexion afin qu'il n'apparaisse pas dans les moteurs de recherche +- Ne pas autoriser l'authentification si Tinyauth ne parvient pas à obtenir les étiquettes + +### Technique + +- Une grande partie du code a été réécrite pour viser un code plus propre, lisible et maintenable +- Structure de fichiers refondue pour une meilleure expérience de développement +- Mise à jour des dépendances +- Mise à jour des traductions + +## v3.6.2 + +### Améliorations + +- Essayer de se reconnecter au serveur LDAP si le battement échoue +- Gérer le type chaîne pour la revendication `groups` dans le fournisseur OAuth générique +- Transférer l'en-tête d'authentification basique aux applications protégées +- Internationaliser les erreurs de saisie requise et invalide +- Ajouter des informations de complétion automatique aux formulaires d'authentification +- Déplacer les requêtes de vérification d'état et favicon vers les journaux de débogage + +### Corrections + +- Ne pas faire échouer l'app si LDAP ne démarre pas mais d'autres sources d'utilisateurs sont configurées + +### Technique + +- Mise à jour des dépendances +- Mise à jour des traductions + +## v3.6.1 + +### Améliorations + +- Utiliser le battement pour empêcher le serveur LDAP de se déconnecter + +### Corrections + +- Corriger le message de mot de passe non traduit + +### Technique + +- Mise à jour des traductions +- Mise à jour des dépendances +- Nettoyer les commentaires dans la base de code + +## v3.6.0 + +### Nouvelles fonctionnalités + +- Prise en charge de l'authentification Tinyauth complètement désactivée pour des IP ou CIDR spécifiques à l'aide de l'étiquette `tinyauth.ip.bypass` + +### Corrections + +- Correction de la découverte d'étiquettes + +### Technique + +- Mise à jour des traductions + +## v3.5.0 + +### Nouvelles fonctionnalités + +- Ajouter une étiquette pour sélectionner l'app en fonction de son domaine, éliminant le besoin de garder le même nom de conteneur que le domaine de l'app +- Prise en charge de la connexion à une application protégée via authentification basique +- Prise en charge de l'autorisation/bloquage d'adresses IP et/ou CIDR +- Prise en charge de l'utilisation d'un serveur LDAP comme source d'utilisateurs + +### Améliorations + +- Passer à Traefik paerser _(pas une faute de frappe)_ pour le parsing des étiquettes au lieu d'une solution personnalisée +- Chiffrer le cookie de session + +### Corrections + +- Corriger l'espacement de l'état d'erreur dans le formulaire de connexion + +### Technique + +- Mise à jour des dépendances +- Mise à jour des traductions +- Exécuter le flux de travail nocturne chaque jour + +## v3.4.1 + +### Technique + +- S'assurer que CGO est désactivé lors de la construction des binaires tinyauth +- Mise à jour des dépendances +- Mise à jour des traductions + +## v3.4.0 + +### Nouvelles fonctionnalités + +- Afficher le hachage de commit et la date de construction aux côtés de la version dans la commande version +- Option d'ignorer la vérification du certificat SSL dans le fournisseur générique + +### Améliorations + +- Re-construire l'UI à partir de zéro en utilisant Shadcn, Tailwind, React Query et React Hook Form +- Négocier la version de l'API avec le hôte Docker au lieu d'échouer +- Supprimer l'en-tête `WWW-Authenticate` pour éviter les fenêtres contextuelles d'authentification basique dans le navigateur +- Stocker la version, la date de construction et le hachage du commit dans des constantes au lieu de fichiers +- Générer des noms de cookies uniques basés sur l'URL de l'app pour éviter les conflits avec d'autres instances +- Utiliser uniquement les redirections 302 pour éviter le cache du navigateur + +### Technique + +- Mise à jour des dépendances +- Déprécier le CDN de traductions +- Mise à jour des traductions +- Créer un flux de travail nocturne de publication +- Supprimer la vérification d'état du Dockerfile car elle causait des erreurs avec un port personnalisé + +## v3.3.1 + +### Améliorations + +- Journaliser lorsqu'on utilise l'e-mail principal GitHub ou le premier disponible + +### Corrections + +- Utiliser l'e-mail au lieu du nom d'utilisateur dans la liste blanche OAuth + +## v3.3.0 + +### Nouvelles fonctionnalités + +- Ajout d'un écran de connexion avertissant lorsque l'URI de redirection ne correspond pas au domaine configuré +- Prise en charge des expressions régulières pour la liste blanche OAuth et utilisateur +- Nouvel écran d'oubli du mot de passe avec la possibilité de changer le texte via Markdown +- Mapper les informations des revendications OIDC aux en-têtes +- Prise en charge de l'auto-redirection vers votre fournisseur OAuth préféré + +### Améliorations + +- Ajouter Dependabot pour les mises à jour des dépendances @gurukulkarni +- Ajout d'un cookie CSRF pour la protection contre le falsage de requête intersite +- Journaliser les erreurs réelles avec le message d'information + +### Corrections + +- Désactiver l'authentification basique pour les utilisateurs TOTP +- Déplacer l'URI de redirection vers un cookie séparé + +### Technique + +- S'assurer que le répertoire dist existe pendant le développement +- Mise à jour des dépendances + +## v3.2.1 + +### Corrections + +- Ignorer les espaces et les nouvelles lignes dans les fichiers secrets +- Supprimer le fournisseur OAuth Tailscale pour des raisons de sécurité + +## v3.2.0 + +### Nouvelles fonctionnalités + +- Internationalisation via [Crowdin](https://crowdin.com/project/tinyauth) et le CDN Tinyauth +- Vérification d'état dans le Dockerfile pour garantir que l'app fonctionne correctement +- Possibilité de dire à tinyauth d'ajouter des en-têtes supplémentaires à la réponse d'authentification (nécessaire pour le futur support du fournisseur OIDC) +- Protection contre les attaques par force brute / limitation de débit par @DragonStuff +- Mode clair +- Les binaires amd64 et arm64 sont désormais disponibles au téléchargement si vous préférez le matériel brut plutôt que Docker + +### Améliorations + +- Diviser l'API en serveur et gestionnaires pour une meilleure lisibilité du code +- Refactorisation de la gestion des erreurs afin de ne pas initialiser de nouvelles variables à chaque erreur +- Tous les services utilisent désormais une seule structure de configuration pour toutes les options de configuration, améliorant ainsi la lisibilité et l'extensibilité du code +- Suppression de la dépendance aux sessions GIN car l'app utilise directement les sessions Gorilla +- L'URI de redirection est désormais stockée dans le cookie de session `tinyauth` + +### Technique + +- Diviser l'API en serveur et gestionnaires pour une meilleure lisibilité du code +- Refactorisation de la gestion des erreurs afin de ne pas initialiser de nouvelles variables à chaque erreur +- Tous les services utilisent désormais une seule structure de configuration pour toutes les options de configuration, améliorant ainsi la lisibilité et l'extensibilité du code +- Suppression de la dépendance aux sessions GIN car l'app utilise directement les sessions Gorilla +- L'URI de redirection est désormais stockée dans le cookie de session `tinyauth` + +## v3.1.0 + +### Nouvelles fonctionnalités + +- Prise en charge de TOTP +- Possibilité de désactiver l'authentification sur des chemins d'app spécifiques via regex +- Possibilité de changer le nom de l'écran de connexion +- Possibilité de changer le nom du bouton du fournisseur OAuth générique +- Tinyauth définit désormais l'en-tête `Remote-User` afin que vous puissiez l'utiliser pour vous connecter à d'autres applications + +### Améliorations + +- Amélioration du gestionnaire Docker pour la vérification des étiquettes +- Amélioration des flux de travail de publication pour des temps de construction plus rapides +- Page de connexion réécrite pour une meilleure modularité +- Fournir des réponses JSON si le client ne accepte pas HTML + +### Corrections + +- Corriger la liste blanche OAuth qui n'autorise aucun utilisateur dans les applications lorsque `null` + +## v3.0.1 + +### Corrections + +- Corriger le fait que l'URI de redirection ne soit pas correctement transmise à l'écran de continuation + +## v3.0.0 + +### Guide de migration + +Pour migrer vers `v3.0.0`, vous devez modifier vos chemins d'authentification. + +Si vous utilisez Traefik pour votre proxy inverse, modifiez l'URL d'authentification directe en `http://tinyauth:3000/api/auth/traefik` + +Si vous utilisez Caddy pour votre proxy inverse, modifiez l'URL d'authentification en `http://tinyauth:3000/api/auth/caddy` + +La variable d'environnement `COOKIE_EXPIRY` a également été renommée en `SESSION_EXPIRY` (`--session-expiry`). + +### Nouvelles fonctionnalités + +- Prise en charge de Nginx / Nginx Proxy Manager +- Authentification aux applications via authentification basique HTTP + +### Améliorations + +- Gérer les valeurs `null` provenant des paramètres de requête plus efficacement dans le front-end. +- Le contenu du cookie expire également en fonction de la variable d'environnement `SESSION_EXPIRY`, augmentant ainsi la sécurité. + +### Corrections + +- Corriger le fait que `OAUTH_WHITELIST` n'autorise aucun utilisateur par défaut. +- Analyser correctement l'URI de redirection pour prendre en charge les anciens navigateurs. + +### Technique + +- Ajouter plusieurs commentaires dans la base de code pour la rendre plus compréhensible. +- Ajouter des tests pour l'API et les utilitaires. + +## v2.1.1 + +### Corrections + +- Vérifier si le démon Docker est disponible avant d'essayer de vérifier les étiquettes de conteneur +- Rediriger vers l'URL de l'app pour la page d'erreur interne du serveur + +## v2.1.0 + +### Nouvelles fonctionnalités + +- Fournisseur OAuth Tailscale +- Contrôles d'accès pour les applications protégées + +### Corrections + +- Supprimer le port du domaine du cookie +- Corriger la configuration OAuth générique qui n'est pas correctement analysée +- Corriger l'affichage des fournisseurs OAuth + +## v2.0.2 + +### Améliorations + +- Gérer correctement la redirection inter-protocole avec un écran de vérification +- L'écran de continuation possède un bouton "retour à l'accueil" lorsqu'aucune URI de redirection n'est fournie +- Le journal ne va plus afficher d'informations sensibles sauf l'adresse e-mail + +### Corrections + +- Diviser correctement le domaine pour tenir compte d'un port personnalisé +- Corriger l'impression du journal d'information de débogage sans niveau de log défini + +## v2.0.1 + +### Corrections + +- Ne pas ajouter de virgule lorsque la variable d'environnement est vide. +- Supprimer les espaces des utilisateurs dans le fichier utilisateur. + +## v2.0.0 + +### Guide de migration + +Pour migrer, vous pouvez simplement changer la variable d'environnement `WHITELIST` en `OAUTH_WHITELIST` et tout fonctionnera correctement. Vous pouvez également revenir à des e-mails comme noms d'utilisateur si vous préférez le nom d'utilisateur/mot de passe mais tinyauth ne vous empêchera pas d'utiliser un e-mail comme nom d'utilisateur. + +### Nouvelles fonctionnalités + +- Nouvelle variable d'environnement `SECRETS_FILE` (`--secrets-file`) permettant d'utiliser un fichier pour stocker le secret de l'app. +- Nouvelle variable d'environnement `GITHUB_CLIENT_SECRET_FILE` (`--github-client-secret-file`) permettant d'utiliser un fichier pour stocker le secret. +- Nouvelle variable d'environnement `GOOGLE_CLIENT_SECRET_FILE` (`--google-client-secret-file`) permettant d'utiliser un fichier pour stocker le secret. +- Nouvelle variable d'environnement `GENERIC_CLIENT_SECRERT_FILE` (`--generic-client-secret-file`) permettant d'utiliser un fichier pour stocker le secret. +- Nouvelle variable d'environnement `LOG_LEVEL` (`--log-level`) permettant d'utiliser le niveau de journalisation debug pour une journalisation détaillée. + +### Améliorations + +- Le jeton OAuth n'est utilisé que pour obtenir l'adresse e-mail utilisateur et il n'est pas stocké sur le client. +- L'écran de connexion vous permet d'utiliser des valeurs non-e-mail. +- La logique du cookie a été réécrite pour utiliser correctement le magasin de cookies. +- Des journaux de débogage ont été ajoutés partout dans l'app pour faciliter le débogage. +- Les utilisateurs ne sont pas une exigence lors de l'utilisation d'OAuth. +- L'analyse des utilisateurs a été réécrite. + +### Corrections + +- Corriger le fait que la variable d'environnement `WHITELIST` ne corresponde pas au drapeau `--oauth-whitelist`. + +## v1.0.0 + +### Guide de migration + +Le seul changement que vous devez effectuer est de convertir votre nom d'utilisateur en adresse e-mail, cela s'applique à la fois aux variables `USERS` et `USERS_FILE`. Voici un exemple : +`user:$$2a$$10$$UdLYoJ5lgPsC0RKqYH/jMua7zIn0g9kPqWmhYayJYLaZQ/FTmH2/u` devient `user@example.com:$$2a$$10$$UdLYoJ5lgPsC0RKqYH/jMua7zIn0g9kPqWmhYayJYLaZQ/FTmH2/u` +Après ce simple changement, modifiez simplement la version tinyauth en `v1.0.0` et elle devrait démarrer normalement. + +### Nouvelles fonctionnalités + +- Prise en charge de Google, GitHub et des fournisseurs OAuth génériques pour l'authentification. +- Option de désactiver l'écran de continuation lors de la connexion et rediriger immédiatement vers l'app. +- Option de définir une expiration personnalisée pour le cookie de session. +- Option de mettre en liste blanche des adresses e-mail spécifiques pour OAuth. + +### Améliorations + +- Toutes les erreurs d'API sont désormais enregistrées et l'utilisateur voit une page d'erreur interne du serveur au lieu de la réponse brute. + +### Corrections + +- Corriger la date d'expiration du cookie définie en mode session. +- Diviser correctement l'URL de l'app. + +## v0.3.0 + +### Nouvelles fonctionnalités + +- Commande de création d'utilisateur +- Commande de vérification d'utilisateur +- Option d'envoyer le cookie uniquement via HTTPS + +### Améliorations + +- Utiliser un modèle d'injection de dépendances pour rendre le code plus lisible + +### Corrections + +- Diviser correctement `APP_URL` afin que le cookie ne soit pas défini pour le domaine racine si des sous-domaines sont utilisés + +## v0.2.0 + +### Nouvelles fonctionnalités + +- Autoriser la configuration d'utilisateurs via un fichier (identique à `.htpasswd`). + +### Améliorations + +- La variable d'environnement `ROOT_URL` n'est plus nécessaire car tinyauth obtient le domaine racine depuis `APP_URL`. +- L'utilisateur est affiché en tant que code dans l'écran de déconnexion. + +### Corrections + +- Corriger l'affichage du bouton de continuation sur l'écran de continuation lorsqu'aucune URI de redirection n'est définie. \ No newline at end of file diff --git a/src/content/docs/fr/docs/reference/cli.mdx b/src/content/docs/fr/docs/reference/cli.mdx new file mode 100644 index 0000000..0da7344 --- /dev/null +++ b/src/content/docs/fr/docs/reference/cli.mdx @@ -0,0 +1,194 @@ +--- +title: "Référence sur le CLI Tinyauth." +description: "Référence sur le CLI Tinyauth." +--- + +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +Tinyauth propose un CLI simple pour configurer l'application et gérer les utilisateurs. + +## Commandes + +Toutes les commandes peuvent être exécutées depuis le binaire autonome de Tinyauth : + +```sh +./tinyauth [options] +``` + +Alternativement, lors de l'exécution de l'application via Docker : + +```sh +docker run -i -t --rm ghcr.io/steveiliop56/tinyauth:v5 [options] +``` + +:::note + Lors de l'utilisation de Docker Compose, la commande `docker compose run tinyauth [options]` peut également être utilisée. +::: + +### Commande principale + +La commande principale démarre l'API et l'interface Web, en attente de connexions entrantes. Toutes les options sont configurables via des drapeaux CLI ou des variables d'environnement. Une liste complète des options de configuration est disponible sur la page [configuration](/docs/reference/configuration). + +### Vérification d'état + +La commande de vérification d'état vérifie si Tinyauth fonctionne correctement : + + + + ```sh + docker compose exec tinyauth healthcheck + ``` + + + ```sh + ./tinyauth healthcheck + ``` + + + +Par défaut, il utilisera `http://127.0.0.1:3000` pour vérifier le point de terminaison d'état. L'URL changera automatiquement si vous définissez les variables d'environnement `TINYAUTH_SERVER_PORT` et `TINYAUTH_SERVER_ADDRESS`. Vous pouvez également spécifier une URL personnalisée avec : + + + + ```sh + docker compose exec tinyauth healthcheck http://tinyauth.example.com + ``` + + + ```sh + ./tinyauth healthcheck http://tinyauth.example.com + ``` + + + +:::note +Il est conseillé de ne pas utiliser la commande de vérification d'état avec l'URL publique de Tinyauth, car cela peut entraîner des problèmes de connexion. Il est recommandé d'utiliser la commande de vérification d'état avec l'URL interne de Tinyauth (par ex., `http://127.0.0.1:3000`). +::: + +### Commande de création d'utilisateur + +La commande de création simplifie la création d'utilisateurs. Pour créer un utilisateur en mode interactif : + + + + ```sh + docker run -i -t --rm ghcr.io/steveiliop56/tinyauth:v5 user create --interactive + ``` + + + ```sh + ./tinyauth user create --interactive + ``` + + + +Cela lance une interface utilisateur en mode texte (TUI) pour saisir un nom d'utilisateur et un mot de passe, générant le format `username:hash` requis par Tinyauth. Elle peut également formater l'utilisateur pour Docker Compose ou les variables d'environnement. Pour la création non interactive : + + + + ```sh + docker run -i -t --rm ghcr.io/steveiliop56/tinyauth:v5 user create --username user@example.com --password password + ``` + + + ```sh + ./tinyauth user create --username user@example.com --password password + ``` + + + +| Option | Description | Valeur par défaut | Obligatoire | +| ------ | ----------- | ----------------- | ----------- | +| `--username` | Nom d'utilisateur pour créer l'utilisateur. | `` | yes | +| `--password` | Mot de passe pour créer l'utilisateur. | `` | yes | +| `--docker` | Formater la sortie pour Docker Compose ou les variables d'environnement. | `false` | no | +| `--interactive` | Utiliser une interface utilisateur en mode texte (TUI) pour créer l'utilisateur. | `false` | no | + +### Vérification d'utilisateur + +La commande de vérification vérifie si un nom d'utilisateur et un mot de passe correspondent au format `username:hash`. Pour la vérification interactive : + + + + ```sh + docker run -i -t --rm ghcr.io/steveiliop56/tinyauth:v5 user verify --interactive + ``` + + + ```sh + ./tinyauth user verify --interactive + ``` + + + +Une interface utilisateur en mode texte (TUI) invite à saisir le `username:hash:secret`, le nom d'utilisateur, le mot de passe et un code TOTP optionnel, vérifiant les informations d'identification. Pour la vérification non interactive : + + + + ```sh + docker run -i -t --rm ghcr.io/steveiliop56/tinyauth:v5 user verify --user 'user@example.com:$2a$10$UdLYoJ5lgPsC0RKqYH/jMua7zIn0g9kPqWmhYayJYLaZQ/FTmH2/u' --username user@example.com --password password + ``` + + + ```sh + ./tinyauth user verify --user 'user@example.com:$2a$10$UdLYoJ5lgPsC0RKqYH/jMua7zIn0g9kPqWmhYayJYLaZQ/FTmH2/u' --username user@example.com --password password + ``` + + + +:::note +Utilisez des guillemets (`'`) dans les shells Bash pour garantir que le hachage est passé correctement. +::: + +| Option | Description | Valeur par défaut | Obligatoire | +| ------ | ----------- | ----------------- | ----------- | +| `--user` | La combinaison `username:hash` à vérifier. | `` | yes | +| `--username` | Nom d'utilisateur pour la vérification. | `` | yes | +| `--password` | Mot de passe pour la vérification. | `` | yes | +| `--interactive` | Utiliser une interface utilisateur en mode texte (TUI) pour la vérification. | `false` | no | +| `--totp` | Code TOTP optionnel pour la vérification. | `` | no | + +### Génération de TOTP + +Tinyauth peut générer automatiquement des codes TOTP pour vous ; la combinaison est `username:hash:secret`. Vous pouvez générer un utilisateur TOTP avec : + + + + ```sh + docker run -i -t --rm ghcr.io/steveiliop56/tinyauth:v5 totp generate --interactive + ``` + + + ```sh + ./tinyauth totp generate --interactive + ``` + + + +Cela invite à saisir le `username:hash` actuel et génère un `username:hash:secret` ainsi qu'un code QR pour l'ajouter à une application d'authentification. Pour la génération non interactive : + + + + ```sh + docker run -i -t --rm ghcr.io/steveiliop56/tinyauth:v5 totp generate --user 'user@example.com:$2a$10$UdLYoJ5lgPsC0RKqYH/jMua7zIn0g9kPqWmhYayJYLaZQ/FTmH2/u' + ``` + + + ```sh + ./tinyauth totp generate --user 'user@example.com:$2a$10$UdLYoJ5lgPsC0RKqYH/jMua7zIn0g9kPqWmhYayJYLaZQ/FTmH2/u' + ``` + + + +:::note +Utilisez des guillemets (`'`) dans les shells Bash pour garantir que le hachage est passé correctement. +::: + +:::note +En raison de la façon dont la bibliothèque de codes QR fonctionne dans Tinyauth, le code QR peut être **énorme** et ne pas tenir sur un écran standard. Si cela se produit, vous pouvez essayer de redimensionner votre fenêtre de terminal ou d'utiliser un émulateur de terminal différent. +::: + +| Option | Description | Valeur par défaut | Obligatoire | +| ------ | ----------- | ----------------- | ----------- | +| `--user` | La combinaison actuelle `username:hash`. | `` | yes | +| `--interactive` | Utiliser une interface utilisateur en mode texte (TUI) pour créer l'utilisateur TOTP. | `false` | no | \ No newline at end of file diff --git a/src/content/docs/fr/docs/reference/configuration.mdx b/src/content/docs/fr/docs/reference/configuration.mdx new file mode 100644 index 0000000..2037a0d --- /dev/null +++ b/src/content/docs/fr/docs/reference/configuration.mdx @@ -0,0 +1,155 @@ +--- +title: "Configuration" +description: "Référence sur la configuration de Tinyauth." +--- + +Tinyauth peut être configuré à l'aide de variables d'environnement ou de paramètres CLI. Le tableau ci‑dessous fournit une liste complète des options de configuration. + +:::note + Les options de configuration avec un équivalent `FILE_` (par ex., `TINYAUTH_AUTH_USERS`/`--auth.users` et + `TINYAUTH_AUTH_USERSFILE`/`--auth.usersfile`) permettent d'utiliser la variable d'environnement ou le paramètre CLI `FILE_` comme alternative. +::: + +## Configuration générale + +| Environnement | Indicateur | Description | Valeur par défaut | +| - | - | - | - | +| `TINYAUTH_APPURL` | `--appurl` | L'URL de base où l'application est hébergée. | `` | + +## Configuration de la base de données + +| Environnement | Indicateur | Description | Valeur par défaut | +| - | - | - | - | +| `TINYAUTH_DATABASE_PATH` | `--database.path` | Le chemin vers la base de données, y compris le nom du fichier. | `./tinyauth.db` | + +## Configuration des analyses + +| Environnement | Indicateur | Description | Valeur par défaut | +| - | - | - | - | +| `TINYAUTH_ANALYTICS_ENABLED` | `--analytics.enabled` | Activer la collecte périodique d'informations sur la version. | `true` | + +## Configuration des ressources + +| Environnement | Indicateur | Description | Valeur par défaut | +| - | - | - | - | +| `TINYAUTH_RESOURCES_ENABLED` | `--resources.enabled` | Activer le serveur de ressources. | `true` | +| `TINYAUTH_RESOURCES_PATH` | `--resources.path` | Le répertoire où les ressources sont stockées. | `./resources` | + +## Configuration du serveur + +| Environnement | Indicateur | Description | Valeur par défaut | +| - | - | - | - | +| `TINYAUTH_SERVER_PORT` | `--server.port` | Le port sur lequel le serveur écoute. | `3000` | +| `TINYAUTH_SERVER_ADDRESS` | `--server.address` | L'adresse sur laquelle le serveur écoute. | `0.0.0.0` | +| `TINYAUTH_SERVER_SOCKETPATH` | `--server.socketpath` | Le chemin vers le socket Unix. | `` | + +## Configuration d'authentification + +| Environnement | Indicateur | Description | Valeur par défaut | +| - | - | - | - | +| `TINYAUTH_AUTH_IP_ALLOW` | `--auth.ip.allow` | Liste des adresses IP ou plages CIDR autorisées. | `` | +| `TINYAUTH_AUTH_IP_BLOCK` | `--auth.ip.block` | Liste des adresses IP ou plages CIDR bloquées. | `` | +| `TINYAUTH_AUTH_USERS` | `--auth.users` | Liste séparée par des virgules d'utilisateurs (nom_d'utilisateur:mot_de_passe_hashé). | `` | +| `TINYAUTH_AUTH_USERSFILE` | `--auth.usersfile` | Chemin vers le fichier des utilisateurs. | `` | +| `TINYAUTH_AUTH_SECURECOOKIE` | `--auth.securecookie` | Activer les cookies sécurisés. | `false` | +| `TINYAUTH_AUTH_SESSIONEXPIRY` | `--auth.sessionexpiry` | Temps d'expiration de la session en secondes. | `86400` | +| `TINYAUTH_AUTH_SESSIONMAXLIFETIME` | `--auth.sessionmaxlifetime` | Durée maximale de vie de la session en secondes. | `0` | +| `TINYAUTH_AUTH_LOGINTIMEOUT` | `--auth.logintimeout` | Délai d'expiration du login en secondes. | `300` | +| `TINYAUTH_AUTH_LOGINMAXRETRIES` | `--auth.loginmaxretries` | Nombre maximal de tentatives de connexion. | `3` | +| `TINYAUTH_AUTH_TRUSTEDPROXIES` | `--auth.trustedproxies` | Liste séparée par des virgules d'adresses de proxys de confiance. | `` | + +## Configuration des ACL + +| Environnement | Indicateur | Description | Valeur par défaut | +| - | - | - | - | +| `TINYAUTH_APPS_[NAME]_CONFIG_DOMAIN` | `--apps.[name].config.domain` | Le domaine de l'application. | `` | +| `TINYAUTH_APPS_[NAME]_USERS_ALLOW` | `--apps.[name].users.allow` | Liste séparée par des virgules d'utilisateurs autorisés. | `` | +| `TINYAUTH_APPS_[NAME]_USERS_BLOCK` | `--apps.[name].users.block` | Liste séparée par des virgules d'utilisateurs bloqués. | `` | +| `TINYAUTH_APPS_[NAME]_OAUTH_WHITELIST` | `--apps.[name].oauth.whitelist` | Liste séparée par des virgules de groupes OAuth autorisés. | `` | +| `TINYAUTH_APPS_[NAME]_OAUTH_GROUPS` | `--apps.[name].oauth.groups` | Liste séparée par des virgules de groupes OAuth requis. | `` | +| `TINYAUTH_APPS_[NAME]_IP_ALLOW` | `--apps.[name].ip.allow` | Liste des adresses IP ou plages CIDR autorisées. | `` | +| `TINYAUTH_APPS_[NAME]_IP_BLOCK` | `--apps.[name].ip.block` | Liste des adresses IP ou plages CIDR bloquées. | `` | +| `TINYAUTH_APPS_[NAME]_IP_BYPASS` | `--apps.[name].ip.bypass` | Liste des adresses IP ou plages CIDR qui contournent l'authentification. | `` | +| `TINYAUTH_APPS_[NAME]_RESPONSE_HEADERS` | `--apps.[name].response.headers` | En-têtes personnalisés à ajouter à la réponse. | `` | +| `TINYAUTH_APPS_[NAME]_RESPONSE_BASICAUTH_USERNAME` | `--apps.[name].response.basicauth.username` | Nom d'utilisateur pour l'authentification basique. | `` | +| `TINYAUTH_APPS_[NAME]_RESPONSE_BASICAUTH_PASSWORD` | `--apps.[name].response.basicauth.password` | Mot de passe pour l'authentification basique. | `` | +| `TINYAUTH_APPS_[NAME]_RESPONSE_BASICAUTH_PASSWORDFILE` | `--apps.[name].response.basicauth.passwordfile` | Chemin vers le fichier contenant le mot de passe d'authentification basique. | `` | +| `TINYAUTH_APPS_[NAME]_PATH_ALLOW` | `--apps.[name].path.allow` | Liste séparée par des virgules de chemins autorisés. | `` | +| `TINYAUTH_APPS_[NAME]_PATH_BLOCK` | `--apps.[name].path.block` | Liste séparée par des virgules de chemins bloqués. | `` | +| `TINYAUTH_APPS_[NAME]_LDAP_GROUPS` | `--apps.[name].ldap.groups` | Liste séparée par des virgules de groupes LDAP requis. | `` | + +## Configuration OAuth + +| Environnement | Indicateur | Description | Valeur par défaut | +| - | - | - | - | +| `TINYAUTH_OAUTH_WHITELIST` | `--oauth.whitelist` | Liste séparée par des virgules de domaines OAuth autorisés. | `` | +| `TINYAUTH_OAUTH_AUTOREDIRECT` | `--oauth.autoredirect` | Le fournisseur OAuth à utiliser pour la redirection automatique. | `` | +| `TINYAUTH_OAUTH_PROVIDERS_[NAME]_CLIENTID` | `--oauth.providers.[name].clientid` | Identifiant du client OAuth. | `` | +| `TINYAUTH_OAUTH_PROVIDERS_[NAME]_CLIENTSECRET` | `--oauth.providers.[name].clientsecret` | Secret du client OAuth. | `` | +| `TINYAUTH_OAUTH_PROVIDERS_[NAME]_CLIENTSECRETFILE` | `--oauth.providers.[name].clientsecretfile` | Chemin vers le fichier contenant le secret du client OAuth. | `` | +| `TINYAUTH_OAUTH_PROVIDERS_[NAME]_SCOPES` | `--oauth.providers.[name].scopes` | Portées OAuth. | `` | +| `TINYAUTH_OAUTH_PROVIDERS_[NAME]_REDIRECTURL` | `--oauth.providers.[name].redirecturl` | URL de redirection OAuth. | `` | +| `TINYAUTH_OAUTH_PROVIDERS_[NAME]_TOKENURL` | `--oauth.providers.[name].tokenurl` | URL du jeton OAuth. | `` | +| `TINYAUTH_OAUTH_PROVIDERS_[NAME]_USERINFOURL` | `--oauth.providers.[name].userinfourl` | URL d'information utilisateur OAuth. | `` | +| `TINYAUTH_OAUTH_PROVIDERS_[NAME]_INSECURE` | `--oauth.providers.[name].insecure` | Autoriser les connexions OAuth non sécurisées. | `false` | +| `TINYAUTH_OAUTH_PROVIDERS_[NAME]_NAME` | `--oauth.providers.[name].name` | Nom du fournisseur dans l'interface utilisateur. | `` | + +:::note + L'utilisation de `google` ou `github` comme identifiants de fournisseur déclenche le remplissage automatique des informations requises (par ex., URL d'authentification, portées). Vous n'aurez à fournir que l'identifiant du client et son secret. +::: + +## Configuration OIDC + +| Environnement | Indicateur | Description | Valeur par défaut | +| - | - | - | - | +| `TINYAUTH_OIDC_PRIVATEKEYPATH` | `--oidc.privatekeypath` | Chemin vers le fichier de clé privée, y compris le nom du fichier. | `./tinyauth_oidc_key` | +| `TINYAUTH_OIDC_PUBLICKEYPATH` | `--oidc.publickeypath` | Chemin vers le fichier de clé publique, y compris le nom du fichier. | `./tinyauth_oidc_key.pub` | +| `TINYAUTH_OIDC_CLIENTS_[NAME]_CLIENTID` | `--oidc.clients.[name].clientid` | Identifiant du client OIDC. | `` | +| `TINYAUTH_OIDC_CLIENTS_[NAME]_CLIENTSECRET` | `--oidc.clients.[name].clientsecret` | Secret du client OIDC. | `` | +| `TINYAUTH_OIDC_CLIENTS_[NAME]_CLIENTSECRETFILE` | `--oidc.clients.[name].clientsecretfile` | Chemin vers le fichier contenant le secret du client OIDC. | `` | +| `TINYAUTH_OIDC_CLIENTS_[NAME]_TRUSTEDREDIRECTURIS` | `--oidc.clients.[name].trustedredirecturis` | Liste des URI de redirection approuvées. | `` | +| `TINYAUTH_OIDC_CLIENTS_[NAME]_NAME` | `--oidc.clients.[name].name` | Nom du client dans l'interface utilisateur. | `` | + +## Configuration de l'UI + +| Environnement | Indicateur | Description | Valeur par défaut | +| - | - | - | - | +| `TINYAUTH_UI_TITLE` | `--ui.title` | Le titre de l'interface utilisateur. | `Tinyauth` | +| `TINYAUTH_UI_FORGOTPASSWORDMESSAGE` | `--ui.forgotpasswordmessage` | Message affiché sur la page de réinitialisation du mot de passe. | `Vous pouvez changer votre mot de passe en modifiant la configuration.` | +| `TINYAUTH_UI_BACKGROUNDIMAGE` | `--ui.backgroundimage` | Chemin vers l'image d'arrière-plan. | `/background.jpg` | +| `TINYAUTH_UI_WARNINGSENABLED` | `--ui.warningsenabled` | Activer les avertissements de l'interface utilisateur. | `true` | + +## Configuration LDAP + +| Environnement | Indicateur | Description | Valeur par défaut | +| - | - | - | - | +| `TINYAUTH_LDAP_ADDRESS` | `--ldap.address` | Adresse du serveur LDAP. | `` | +| `TINYAUTH_LDAP_BINDDN` | `--ldap.binddn` | DN de liaison pour l'authentification LDAP. | `` | +| `TINYAUTH_LDAP_BINDPASSWORD` | `--ldap.bindpassword` | Mot de passe de liaison pour l'authentification LDAP. | `` | +| `TINYAUTH_LDAP_BASEDN` | `--ldap.basedn` | DN de base pour les recherches LDAP. | `` | +| `TINYAUTH_LDAP_INSECURE` | `--ldap.insecure` | Autoriser les connexions LDAP non sécurisées. | `false` | +| `TINYAUTH_LDAP_SEARCHFILTER` | `--ldap.searchfilter` | Filtre de recherche LDAP. | `(uid=%s)` | +| `TINYAUTH_LDAP_AUTHCERT` | `--ldap.authcert` | Certificat pour l'authentification mTLS. | `` | +| `TINYAUTH_LDAP_AUTHKEY` | `--ldap.authkey` | Clé du certificat pour l'authentification mTLS. | `` | +| `TINYAUTH_LDAP_GROUPCACHETTL` | `--ldap.groupcachettl` | Durée de mise en cache de la participation aux groupes LDAP, en secondes. | `900` | + +:::note + Pour le LDAP sous Windows, utilisez le filtre de recherche suivant : `(&(sAMAccountName=%s))`. +::: + +## Configuration du journal + +| Environnement | Indicateur | Description | Valeur par défaut | +| - | - | - | - | +| `TINYAUTH_LOG_LEVEL` | `--log.level` | Niveau de journalisation (trace, debug, info, warn, error). | `info` | +| `TINYAUTH_LOG_JSON` | `--log.json` | Activer les journaux formatés en JSON. | `false` | +| `TINYAUTH_LOG_STREAMS_HTTP_ENABLED` | `--log.streams.http.enabled` | Activer ce flux de journalisation. | `true` | +| `TINYAUTH_LOG_STREAMS_HTTP_LEVEL` | `--log.streams.http.level` | Niveau de journalisation pour ce flux. Utiliser le niveau global si vide. | `` | +| `TINYAUTH_LOG_STREAMS_APP_ENABLED` | `--log.streams.app.enabled` | Activer ce flux de journalisation. | `true` | +| `TINYAUTH_LOG_STREAMS_APP_LEVEL` | `--log.streams.app.level` | Niveau de journalisation pour ce flux. Utiliser le niveau global si vide. | `` | +| `TINYAUTH_LOG_STREAMS_AUDIT_ENABLED` | `--log.streams.audit.enabled` | Activer ce flux de journalisation. | `false` | +| `TINYAUTH_LOG_STREAMS_AUDIT_LEVEL` | `--log.streams.audit.level` | Niveau de journalisation pour ce flux. Utiliser le niveau global si vide. | `` | + +:::caution + Le niveau de journalisation `trace` enregistrera des informations sensibles telles que les noms d'utilisateur, les e-mails et les contrôles d'accès. +::: \ No newline at end of file diff --git a/src/content/docs/fr/docs/reference/flow.mdx b/src/content/docs/fr/docs/reference/flow.mdx new file mode 100644 index 0000000..5012460 --- /dev/null +++ b/src/content/docs/fr/docs/reference/flow.mdx @@ -0,0 +1,21 @@ +--- +title: "Flux" +description: "Référence sur le flux d'authentification de Tinyauth." +--- + +Tinyauth fonctionne avec un processus d'authentification simple. Le diagramme de séquence ci-dessous illustre le flux d'authentification : + +```mermaid +sequenceDiagram + User->>Proxy: Request resource + Proxy->>Tinyauth: Forward auth request + Tinyauth->>User: Login screen + User->>Tinyauth: Login + Tinyauth->>User: Set cookie + Tinyauth->>User: Redirect to resource + User->>Proxy: Request resource + Proxy->>Tinyauth: Forward auth request + Tinyauth->>Proxy: Success + Proxy->>App: User request + App->>User: Response +``` diff --git a/src/content/docs/fr/docs/reference/headers.mdx b/src/content/docs/fr/docs/reference/headers.mdx new file mode 100644 index 0000000..525fcf2 --- /dev/null +++ b/src/content/docs/fr/docs/reference/headers.mdx @@ -0,0 +1,119 @@ +--- +title: "Référence sur la prise en charge des en‑têtes par Tinyauth." +description: "Référence sur la prise en charge des en‑têtes par Tinyauth." +--- + +Setting headers can be useful for authenticating to apps with the credentials from Tinyauth. While Tinyauth offers some defaults, it also allows setting custom headers that are automatically returned in the authentication server response. This is particularly useful for applications that support header-based authentication, where the app relies on the reverse proxy to provide authentication and user information. + +:::note + Headers are case-insensitive. For example, both `Remote-User` and + `remote-user` are valid. +::: + +## Supported Headers + +### Remote user + +The `Remote-User` header contains the username of the currently logged-in user. For OAuth providers, the `preferred_username` claim from the OIDC response is used. If unavailable, a pseudo username is generated using the email address in the format `username_domain.com`. + +### Remote email + +The `Remote-Email` header contains the email of the currently logged-in user. For username/password authentication, a pseudo email address is created using the username and the configured domain. For OAuth, the email is retrieved from the `email` claim. + +### Remote name + +The `Remote-Name` header contains the full name of the currently logged-in user. If the `name` claim is unavailable, a pseudo name is generated using the username or email in formats like `User` or `User (example.com)`. + +### Remote groups + +The `Remote-Groups` header contains the groups of the currently logged-in user, retrieved from the `groups` claim in the OIDC server or from the LDAP server. These can be used to allow access to specific user groups configured by the OIDC or LDAP server. More details are available in the [OIDC access controls](/docs/guides/access-controls#access-controls-using-oidc-groups) and [LDAP access controls](/docs/guides/access-controls#access-controls-using-ldap-groups) guides. + +:::caution + Remote groups are only available for OIDC providers that support the `groups` + claim. +::: + +### Remote sub + +The `Remote-Sub` header contains the subject identifier of the currently logged-in user, retrieved from the `sub` claim in the OIDC server. This can be used to uniquely identify the user across different authentication providers. + +### Custom headers + +Custom headers can be set using the `tinyauth.headers` label on any container that uses the Tinyauth middleware. For example: + +```yaml +tinyauth.apps.[app].response.headers: my-header=cool +``` + +When authenticating through Tinyauth, the app will receive the `my-header` header. + +:::caution + Ensure a list of trusted proxy URLs is configured for the app. Accepting + headers from untrusted proxies can lead to security vulnerabilities. +::: + +:::note + By default, Tinyauth uses the subdomain name of the request to find a matching + container for labels. For example, a request to `myapp.example.com` checks for + labels that have the subdomain as the app ID. This behavior can be modified + using the `tinyauth.apps.[app].config.domain` label. More details are + available in the [access + controls](/docs/guides/access-controls#label-discovery) guide. +::: + +## Adding Headers to Proxy + +Configuring the proxy to forward headers ensures they are included in responses. The configuration varies depending on the proxy. + +### Traefik + +Add the following label to the Tinyauth container: + +```yaml +traefik.http.middlewares.tinyauth.forwardauth.authResponseHeaders: remote-user # This can be a comma separated list of more headers you will like to copy like the custom ones you set +``` + +Multiple headers can be added as a comma-separated list. + +### Caddy + +Add the following label to the Caddy configuration: + +```yaml +caddy.forward_auth.copy_headers: remote-user +``` + +Multiple headers are separated by spaces, for example: `remote-user remote-name remote-email remote-groups`. + +### Nginx/Nginx Proxy Manager + +Insert the following lines after the `error_page 401 = @tinyauth_login;` directive: + +```shell +auth_request_set $tinyauth_remote_user $upstream_http_remote_user; +proxy_set_header remote-user $tinyauth_remote_user; +``` + +Additional headers can be added by repeating the steps. For example: + +```shell +auth_request_set $my_header $upstream_http_my_header; +proxy_set_header my-header $my_header; +``` + +#### x-tinyauth-location + +For API requests (non-browser requests), Tinyauth sets the `x-tinyauth-location` header in error responses. This header contains the URL where Tinyauth wants the user to be redirected, such as `/login`, `/unauthorized`, or `/error` endpoints with appropriate query parameters. + +This header is particularly useful for Nginx configurations where the error page handler can read this header and redirect accordingly, instead of hardcoding redirect URLs in the Nginx configuration. For example: + +```shell +error_page 401 = @tinyauth_error; +error_page 403 = @tinyauth_error; +error_page 500 = @tinyauth_error; + +location @tinyauth_error { + auth_request_set $redirect_url $upstream_http_x_tinyauth_location; + return 307 $redirect_url; +} +``` \ No newline at end of file diff --git a/src/content/docs/fr/docs/reference/labels.mdx b/src/content/docs/fr/docs/reference/labels.mdx new file mode 100644 index 0000000..ca295d8 --- /dev/null +++ b/src/content/docs/fr/docs/reference/labels.mdx @@ -0,0 +1,40 @@ +--- +title: "Étiquettes" +description: "Référence sur les étiquettes utilisées par Tinyauth." +--- + +Tinyauth utilise des étiquettes pour gérer le contrôle d'accès aux ressources protégées. Les étiquettes sont des paires clé-valeur pouvant être attribuées à des utilisateurs et des ressources, permettant un contrôle d'accès flexible et granulaire. La liste complète des étiquettes est disponible ci-dessous. + +## Discovery + +Tinyauth utilise l'ID de l'application dans les étiquettes et le sous-domaine de la requête pour faire correspondre les étiquettes avec l'application. Par exemple, une requête vers `app1.example.com` déclenche Tinyauth à rechercher des conteneurs avec l'étiquette `tinyauth.apps.app1.foo: bar`. Pour utiliser le domaine à la place, ajoutez l'étiquette suivante : + +```yaml +tinyauth.apps.myapp.config.domain: myapp.example.com +``` + +Tinyauth utilisera désormais le domaine pour faire correspondre les étiquettes au lieu de l'ID de l'application. + +:::note + Les étiquettes peuvent être définies soit sur le conteneur Tinyauth, soit sur l'application. Cependant, si vous utilisez plusieurs hôtes et que l'application s'exécute sur un hôte différent de celui de Tinyauth, les étiquettes doivent être définies sur le conteneur Tinyauth. +::: + +## Full List + +| Nom | Description | +| ----------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | +| `tinyauth.apps.[app].config.domain` | Le domaine où l'application protégée est exposée. Tinyauth utilisera ceci pour identifier le conteneur correct. | +| `tinyauth.apps.[app].users.allow` | Une liste séparée par des virgules d'utilisateurs autorisés à accéder à l'application. | +| `tinyauth.apps.[app].users.block` | Une liste séparée par des virgules d'utilisateurs non autorisés à accéder à l'application. | +| `tinyauth.apps.[app].oauth.whitelist` | Une liste séparée par des virgules ou une expression régulière d'adresses e‑mail autorisées à accéder à l'application (provenant d'OAuth). | +| `tinyauth.apps.[app].oauth.groups` | Une liste séparée par des virgules de groupes OAuth requis pour qu'un utilisateur accède à l'application. | +| `tinyauth.apps.[app].ip.allow` | Une liste séparée par des virgules d'adresses IP ou de CIDR autorisées à accéder à l'application. | +| `tinyauth.apps.[app].ip.block` | Une liste séparée par des virgules d'adresses IP ou de CIDR non autorisées à accéder à l'application. | +| `tinyauth.apps.[app].ip.bypass` | Une liste séparée par des virgules d'adresses IP ou de CIDR pour lesquelles l'authentification ne sera pas requise afin d'accéder à l'application. | +| `tinyauth.apps.[app].response.headers` | Une liste séparée par des virgules d'en-têtes que Tinyauth inclura dans sa réponse (utile pour l'authentification aux applications protégées avec des jetons). | +| `tinyauth.apps.[app].response.basicauth.username` | Nom d'utilisateur utilisé par Tinyauth pour s'authentifier à une application cible via l'authentification basique. | +| `tinyauth.apps.[app].response.basicauth.password` | Mot de passe utilisé par Tinyauth pour s'authentifier à une application cible via l'authentification basique. | +| `tinyauth.apps.[app].response.basicauth.passwordfile` | Un chemin vers un fichier contenant le mot de passe utilisé par Tinyauth pour s'authentifier à une application cible via l'authentification basique. | +| `tinyauth.apps.[app].path.allow` | Une expression régulière d'itinéraires qui ne nécessitent pas d'authentification. | +| `tinyauth.apps.[app].path.block` | Une expression régulière d'itinéraires qui nécessiteront une authentification (les autres itinéraires étant autorisés). | +| `tinyauth.apps.[app].ldap.groups` | Une liste séparée par des virgules de groupes LDAP requis pour qu'un utilisateur accède à l'application. | \ No newline at end of file diff --git a/src/content/docs/fr/docs/reference/telemetry.mdx b/src/content/docs/fr/docs/reference/telemetry.mdx new file mode 100644 index 0000000..94fa56b --- /dev/null +++ b/src/content/docs/fr/docs/reference/telemetry.mdx @@ -0,0 +1,26 @@ +--- +title: "Télémétrie" +description: "Informations sur la télémétrie dans Tinyauth." +--- + +Tinyauth inclut une fonction de battement qui envoie des informations de version anonymes afin d’obtenir quelques aperçus sur l’utilisation de Tinyauth. Les informations collectées comprennent : + +- Version de Tinyauth +- UUID de l’instance (généré avec UUID v4 à partir de l'URL de l'application) +- Heure de la requête + +:::note + Le UUID généré à partir de l'URL de l'application est un hachage irréversible et ne peut pas être utilisé pour identifier l’instance. +::: + +Les données sont envoyées à `https://api.tinyauth.app/v1/instances/hearbeat` toutes les 12 heures. Aucune information personnelle, sensible ou identifiables n’est collectée. Le battement peut être désactivé avec : + +| Environnement | Indicateur CLI | Par défaut | +| ------------------- | --------------------- | ------- | +| `TINYAUTH_ANALYTICS_ENABLED` | `--analytics.enabled` | `false` | + +:::note + Votre adresse IP peut être stockée dans un cache en mémoire pendant une courte période afin de prévenir les abus du serveur d'API. +::: + +Le code source du serveur de télémétrie est disponible sur [GitHub](https://github.com/tinyauthapp/analytics) sous licence MIT. \ No newline at end of file diff --git a/src/content/i18n/en.json b/src/content/i18n/en.json new file mode 100644 index 0000000..9e26dfe --- /dev/null +++ b/src/content/i18n/en.json @@ -0,0 +1 @@ +{} \ No newline at end of file diff --git a/src/content/i18n/fr.json b/src/content/i18n/fr.json new file mode 100644 index 0000000..3a44bf0 --- /dev/null +++ b/src/content/i18n/fr.json @@ -0,0 +1,5 @@ +{ + "search.label": "Rechercher", + "themeSelect.accessibleLabel": "Sélectionner le thème", + "hero.fileIssue": "Signaler un problème" +} \ No newline at end of file