# Clé obsolète dans access.lua (protect\_against\_basic\_auth\_spoofing)
**URL:** https://forum.yunohost.org/t/cle-obsolete-dans-access-lua-protect-against-basic-auth-spoofing/43094
**Category:** Discuss
**Tags:** french, bug
**Created:** [September 30, 2026, 7:14pm UTC](https://forum.yunohost.org/t/cle-obsolete-dans-access-lua-protect-against-basic-auth-spoofing/43094 "2026-09-30T19:14:20Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@Bachy](https://forum.yunohost.org/u/Bachy)
#### Post date: [September 30, 2026, 7:14pm UTC](https://forum.yunohost.org/t/cle-obsolete-dans-access-lua-protect-against-basic-auth-spoofing/43094/1 "2026-09-30T19:14:20Z")
### I have searched the forum for similar discussions
on
### I understand this category is for discussions, not support requests, and not for app requests.
on
### This form is written in English but feel free to write in French if you’re more comfortable!
on
### Discuss
Salut,
Avant toute chose je précise que j’ai rédigé ce post avec GLM5.3 dans mistral-vibe.
Pas sur que discuss soit le meilleurs endroit, mais support ne me parraissait pas mieux.
Contexte : YunoHost 12.1.40, app kanboard\_ynh (path /kanboard), objectif d’utiliser l’API JSON-RPC de Kanboard en auth basic jsonrpc: (jeton de la page Settings → API) pour de l’automatisation.
Symptôme : toute requête authentifiée sur [https://domain.tld/kanboard/jsonrpc.php](https://domain.tld/kanboard/jsonrpc.php) retourne 401 côté Kanboard, quel que soit le token. Une requête sans auth donne le même 401 : le header n’arrive jamais à l’app.
Ce que j’ai vérifié (dans l’ordre) :
1. Le vhost nginx kanboard passe bien le header à PHP : fastcgi\_param HTTP\_AUTHORIZATION $http\_authorization; est en place — insuffisant.
2. Les modes d’auth Kanboard (lus dans le source app/Api/Middleware/AuthenticationMiddleware.php) : mode app = jsonrpc + jeton applicatif (configModel-\>get(‘api\_token’)), mode utilisateur = username + jeton profil (uniquement si 2FA). Les tokens testés étaient les bons.
3. Le lua de SSOwat (/usr/share/ssowat/access.lua, section anti-spoofing, lignes 269-279) :
if permission ~= nil and ngx.req.get\_headers()[“Authorization”] ~= nil then
if permission[“protect\_against\_basic\_auth\_spoofing”] ~= false then
– … on interprète comme du spoofing
ngx.req.clear\_header(“Authorization”)
4. La conf générée par ssowatconf ne contient jamais cette clé. Les objets permissions de /etc/ssowat/conf.json ne portent que : auth\_header (valeur False ou “basic-with-password”), public, uris, users. Vérifié après ajout d’une permission dédiée dans /etc/yunohost/apps/kanboard/settings.yml :
api:
allowed: [visitors]
auth\_header: false
url: /jsonrpc.php
→ la permission est bien générée dans conf.json (auth\_header: False, la bonne URI), mais la clé protect\_against\_basic\_auth\_spoofing est filtrée par le générateur, même si on l’ajoute au settings.yml.
Conséquence : permission[“protect\_against\_basic\_auth\_spoofing”] vaut toujours nil, donc nil ~= false est toujours vrai → le header Basic est systématiquement effacé pour toute requête matchant une permission. Le flag auth\_header: false (qui semble précisément conçu pour exempter une URL de ce strip, cf. les apps à API basic-auth) ne peut pas fonctionner : le lua et le générateur de conf ne parlent plus le même nom de clé.
Contournement proposé (une ligne, /usr/share/ssowat/access.lua) :
– remplacer
if permission[“protect\_against\_basic\_auth\_spoofing”] ~= false then
– par
if permission[“auth\_header”] ~= false then
puis systemctl reload nginx.
Sémantique : les permissions normales (auth\_header = true / “basic-with-password”) continuent d’être protégées contre le spoofing ; seules les permissions explicitement déclarées auth\_header: false laissent passer le header du client. Avec la permission kanboard.api ci-dessus, seul /kanboard/jsonrpc.php est exempté.
Mes questions avant de le faire :
1. Quelqu’un confirme que c’est bien une clé obsolète/renommée oubliée dans access.lua, et non une clé encore émise quelque part par une autre voie ?
2. Existe-t-il un fix officiel en cours (issue/PR) sur ce point ?
3. Le patch vous semble-t-il raisonnable, ou y a-t-il une approche plus propre qui ne touche pas /usr/share/ssowat (sachant que le fichier sera écrasé aux upgrades YunoHost) ?
4. Plus généralement : comment gérez-vous les apps dont l’API utilise son propre basic-auth derrière SSOwat sur du 12.x ?
Merci d’avance pour vos retours.
---
### Author:  [@otm33](https://forum.yunohost.org/u/otm33)
#### Post date: [September 30, 2026, 7:36pm UTC](https://forum.yunohost.org/t/cle-obsolete-dans-access-lua-protect-against-basic-auth-spoofing/43094/2 "2026-09-30T19:36:30Z")
Bonsoir @Bachy
Le cas de figure est documenté. Par défaut, `protect_against_basic_auth_spoofing` est effectivement `true`.
```auto
sudo yunohost app setting kanboard protect_against_basic_auth_spoofing -v "false"
sudo yunohost app ssowatconf
```
---
### Author:  [@Bachy](https://forum.yunohost.org/u/Bachy)
#### Post date: [September 30, 2026, 11:08pm UTC](https://forum.yunohost.org/t/cle-obsolete-dans-access-lua-protect-against-basic-auth-spoofing/43094/3 "2026-09-30T23:08:05Z")
merci @otm33