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 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) :
- Le vhost nginx kanboard passe bien le header à PHP : fastcgi_param HTTP_AUTHORIZATION $http_authorization; est en place — insuffisant.
- 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.
- 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”) - 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 :
- 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 ?
- Existe-t-il un fix officiel en cours (issue/PR) sur ce point ?
- 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) ?
- 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.