Djeex/docudjeex
1
1
Fork 0
Code Issues Pull Requests Actions Projects Wiki Activity

Fix TinyAuth's Uptime-Kuma public-paths example: mislabeled tag and over-broad /api and /metrics exposure

Browse Source
This commit is contained in:
Djeex
2026-09-07 13:42:48 +02:00
parent 81c54c9afc
commit d1f3f4ff88
2 changed files with 10 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/3.serveex/3.security/3.tinyauth.md
+4 -4
View File
@@ -12,7 +12,7 @@ description: Install TinyAuth, a lightweight forward-auth proxy, and pair it wit
It supports a simple local username/password login out of the box, which is what we'll set up here. It can also delegate login to an external OIDC provider like [Pocket ID](/serveex/security/pocket-id) instead, so anyone visiting a protected app authenticates with a passkey via Pocket ID and then gets forwarded through: install Pocket ID afterwards and follow [its guide](/serveex/security/pocket-id#connecting-pocket-id-to-tinyauth) to connect the two. It supports a simple local username/password login out of the box, which is what we'll set up here. It can also delegate login to an external OIDC provider like [Pocket ID](/serveex/security/pocket-id) instead, so anyone visiting a protected app authenticates with a passkey via Pocket ID and then gets forwarded through: install Pocket ID afterwards and follow [its guide](/serveex/security/pocket-id#connecting-pocket-id-to-tinyauth) to connect the two.
- [TinyAuth documentation](https://tinyauth.app/docs) - [TinyAuth documentation](https://tinyauth.app/docs/getting-started)
- [TinyAuth on GitHub](https://github.com/tinyauthapp/tinyauth) - [TinyAuth on GitHub](https://github.com/tinyauthapp/tinyauth)
## Installation ## Installation
@@ -299,9 +299,9 @@ Sometimes you want most of an app locked behind TinyAuth, but a handful of paths
A regex `location` block always takes priority over the plain `location /` block, no matter which one appears first in the file. So any path matched by a regex location you define runs its own `proxy_pass`, without ever reaching the `auth_request /tinyauth;` line in `location /`. A regex `location` block always takes priority over the plain `location /` block, no matter which one appears first in the file. So any path matched by a regex location you define runs its own `proxy_pass`, without ever reaching the `auth_request /tinyauth;` line in `location /`.
For example, to leave Uptime-Kuma's public status page and its assets open while protecting everything else: For example, here's how to leave Uptime-Kuma's public status page and its assets open while protecting everything else. Only `api/status-page` is left public, not all of `/api`, since the rest of Uptime-Kuma's API is meant to stay behind authentication; `/metrics` (Uptime-Kuma's Prometheus endpoint) is left out of the regex entirely for the same reason:
```nginx [dockge.subdomain.conf]{9-16} ```nginx [uptime-kuma.subdomain.conf]{9-16}
server { server {
listen 443 ssl; listen 443 ssl;
listen [::]:443 ssl; listen [::]:443 ssl;
@@ -310,7 +310,7 @@ server {
include /config/nginx/ssl.conf; include /config/nginx/ssl.conf;
location ~ ^/(status|assets|icon\.svg|api|upload|metrics) { location ~ ^/(status|assets|icon\.svg|api/status-page|upload) {
include /config/nginx/proxy.conf; include /config/nginx/proxy.conf;
include /config/nginx/resolver.conf; include /config/nginx/resolver.conf;
set $upstream_app uptime-kuma; set $upstream_app uptime-kuma;
content/fr/3.serveex/3.security/3.tinyauth.md
+6 -6
View File
@@ -10,9 +10,9 @@ description: Installer TinyAuth, un proxy de forward-auth léger, et l'associer
![tinyauth](/img/serveex/tinyauth.png) ![tinyauth](/img/serveex/tinyauth.png)
Nativement il gère une simple connexion locale identifiant/mot de passe, c'est ce que nous mettrons en place ici. Il peut aussi déléguer la connexion à un fournisseur OIDC externe comme [Pocket ID](/serveex/security/pocket-id), de sorte que quiconque visite une application protégée s'authentifie avec une passkey via Pocket ID puis est redirigé : installez Pocket ID ensuite et suivez [son tutoriel](/serveex/security/pocket-id#connecting-pocket-id-to-tinyauth) pour relier les deux. Nativement il gère une simple connexion locale identifiant/mot de passe, c'est ce que nous mettrons en place ici. Il peut aussi déléguer la connexion à un fournisseur OIDC externe comme [Pocket ID](/serveex/security/pocket-id), de sorte que quiconque visite une application protégée s'authentifie avec une passkey via Pocket ID puis est redirigé : installez Pocket ID ensuite et suivez [son tutoriel](/serveex/security/pocket-id#connecter-pocket-id-à-tinyauth) pour relier les deux.
- [Documentation de TinyAuth](https://tinyauth.app/docs) - [Documentation de TinyAuth](https://tinyauth.app/docs/getting-started)
- [TinyAuth sur GitHub](https://github.com/tinyauthapp/tinyauth) - [TinyAuth sur GitHub](https://github.com/tinyauthapp/tinyauth)
## Installation ## Installation
@@ -277,7 +277,7 @@ server {
} }
``` ```
::note{to="/serveex/security/tinyauth#exposing-tinyauth-with-swag"} ::note{to="/serveex/security/tinyauth#exposer-tinyauth-avec-swag"}
Le bloc `location /tinyauth` s'exécute dans le conteneur de SWAG lui-même, SWAG doit donc être sur le réseau Docker de TinyAuth pour le joindre par son nom (`tinyauth` ici). Cela devrait déjà être en place depuis **l'exposition de TinyAuth**. Si vous rencontrez une erreur, revérifiez que le fichier compose de SWAG a toujours ce réseau rattaché. Le bloc `location /tinyauth` s'exécute dans le conteneur de SWAG lui-même, SWAG doit donc être sur le réseau Docker de TinyAuth pour le joindre par son nom (`tinyauth` ici). Cela devrait déjà être en place depuis **l'exposition de TinyAuth**. Si vous rencontrez une erreur, revérifiez que le fichier compose de SWAG a toujours ce réseau rattaché.
:: ::
@@ -299,9 +299,9 @@ Il arrive qu'on veuille verrouiller l'essentiel d'une application derrière Tiny
Un bloc `location` en expression régulière est toujours prioritaire sur le bloc `location /` simple, quel que soit celui qui apparaît en premier dans le fichier. Tout chemin correspondant à une location en regex que vous définissez exécute donc son propre `proxy_pass`, sans jamais atteindre la ligne `auth_request /tinyauth;` du `location /`. Un bloc `location` en expression régulière est toujours prioritaire sur le bloc `location /` simple, quel que soit celui qui apparaît en premier dans le fichier. Tout chemin correspondant à une location en regex que vous définissez exécute donc son propre `proxy_pass`, sans jamais atteindre la ligne `auth_request /tinyauth;` du `location /`.
Par exemple, pour laisser ouverte la page de statut publique d'Uptime-Kuma et ses ressources tout en protégeant le reste : Par exemple, voici comment laisser ouverte la page de statut publique d'Uptime-Kuma et ses ressources tout en protégeant le reste. Seul `api/status-page` est laissé public, pas tout `/api`, car le reste de l'API d'Uptime-Kuma doit rester derrière l'authentification ; `/metrics` (l'endpoint Prometheus d'Uptime-Kuma) est volontairement absent de la regex pour la même raison :
```nginx [dockge.subdomain.conf]{9-16} ```nginx [uptime-kuma.subdomain.conf]{9-16}
server { server {
listen 443 ssl; listen 443 ssl;
listen [::]:443 ssl; listen [::]:443 ssl;
@@ -310,7 +310,7 @@ server {
include /config/nginx/ssl.conf; include /config/nginx/ssl.conf;
location ~ ^/(status|assets|icon\.svg|api|upload|metrics) { location ~ ^/(status|assets|icon\.svg|api/status-page|upload) {
include /config/nginx/proxy.conf; include /config/nginx/proxy.conf;
include /config/nginx/resolver.conf; include /config/nginx/resolver.conf;
set $upstream_app uptime-kuma; set $upstream_app uptime-kuma;