Dépannage : authentification, e-mail et MCP

Une fois le serveur démarré, la classe de problèmes suivante vient des services empilés par-dessus. Voici ceux qui surprennent le plus — les deux premiers parce que ce sont des avertissements et non des échecs : l'application a l'air en bonne santé pendant que quelque chose ne marche plus, en silence. Et ceux de MCP pour la raison inverse : un refus net de démarrer, sur une variable qui était correcte hier.

Auth : « JWT signing keys could not be read »

⚠ 2 JWT signing keys could not be read with the current auth secret and were
  regenerated — previously issued tokens are no longer valid
⚠ 5 stored connection tokens encrypted with a different key — affected users
  must reconnect

Deux avertissements, une seule cause : la clé de chiffrement a changé entre ce démarrage et le précédent. Sauf si vous définissez AUTH_SECRET vous-même, il dérive de cette clé — une nouvelle clé fait donc aussi tourner le secret de signature, et tout ce qui était scellé avec l'ancienne cesse de s'ouvrir.

Presque toujours, la clé n'avait jamais été persistée. Lis la ligne située juste au-dessus, dans la même bannière :

✓ Encryption key: generated at /var/lib/sovrium/encryption-key

generated at sur un redémarrage — là où une installation stabilisée affiche from — signifie que le répertoire de données n'a pas survécu : la clé est neuve à chaque démarrage pendant que la base conserve l'ancien chiffré. C'est la configuration à système de fichiers éphémère : un conteneur sans volume, ou une plateforme qui reconstruit le système de fichiers à chaque déploiement. Fixe SOVRIUM_ENCRYPTION_KEY sur une valeur stable et cela cesse — voir Secrets.

Les deux cas sont traités différemment à dessein. Une clé de signature est du matériel dérivé : Sovrium la régénère, et le seul coût est que les jetons déjà émis ne se vérifient plus. Un jeton de connexion est un accès délégué au compte tiers de quelqu'un : il est laissé exactement en l'état et seulement signalé. Ces personnes reconnectent l'intégration elles-mêmes ; rien n'est jeté à leur place.

« Email sending disabled — SMTP not configured »

Email sending disabled — SMTP not configured (set SMTP_HOST to enable)

Un avertissement, pas un échec — et d'autant plus dangereux. L'application démarre, l'inscription réussit, la réinitialisation de mot de passe renvoie 200. Le courrier est écrit dans le journal au lieu d'être envoyé : les liens n'arrivent donc jamais, et le parcours ne paraît cassé que du côté de l'utilisateur.

Définis SMTP_HOST et ses compagnes pour activer l'envoi :

SMTP_HOST=smtp.example.com
SMTP_PORT=587          # défaut
SMTP_USER=apikey
SMTP_PASS=<secret>

Voir Variables d'environnement pour l'ensemble complet, et Intégration e-mail pour la configuration côté fournisseur. Tout ce qui touche à la vérification d'e-mail ou à la réinitialisation de mot de passe devrait être testé contre un vrai serveur SMTP avant livraison.

MCP : « the MCP static tokens were removed »

MCP_TOKEN_ADMIN is set, but the MCP static tokens were removed. They had no user
identity, so the row-level user_access tier never ran for a token-authenticated
caller. Issue an API key instead (app.auth.apiKeys) and present it on the
x-api-key header, then unset MCP_TOKEN_ADMIN.

MCP_TOKEN_ADMIN, MCP_TOKEN_MEMBER et MCP_TOKEN_VIEWER n'existent plus. Si votre instance en définit encore un et que MCP_ENABLED=true, le serveur refuse de démarrer — délibérément. Ignorer la variable serait pire : vous croiriez /mcp gardé par le secret que vous avez émis, alors qu'il est gardé par tout autre chose.

Le correctif tient en trois étapes :

# 1. Retirer les variables retirées
unset MCP_TOKEN_ADMIN MCP_TOKEN_MEMBER MCP_TOKEN_VIEWER MCP_AUTH_STRATEGY

# 2. S'assurer que l'application a une authentification, clés en libre-service activées
auth:
  strategies:
    - type: emailAndPassword
  apiKeys: true

1. Connecte-toi avec l'utilisateur dont le client doit hériter du rôle, émets une clé d'API, et envoie-la sur l'en-tête x-api-key — pas Authorization: Bearer.

Le rôle n'est plus figé dans l'identifiant : une clé agit comme son propriétaire, résolu en direct à chaque appel. Rétrograde cet utilisateur et toutes ses clés se restreignent avec lui ; bannis-le et ses clés cessent de fonctionner. C'est précisément ce que les jetons statiques ne savaient pas faire — ne portant aucun utilisateur, ils ne déclenchaient jamais les règles au niveau ligne.

MCP : « MCP_AUTH_STRATEGY=token names a strategy that no longer exists »

MCP_AUTH_STRATEGY=token names a strategy that no longer exists. /mcp now
dispatches on the header a request carries: x-api-key is verified as an API key,
Authorization: Bearer as an OAuth access token. Unset MCP_AUTH_STRATEGY (oauth2
is still accepted as a deprecated no-op).

Il n'y a plus de stratégie à choisir. /mcp détermine le vérificateur à partir de l'en-tête que la requête présente réellement, si bien que les deux identifiants sont actifs en même temps — un utilisateur de Claude Desktop en OAuth et un job de CI porteur d'une clé d'API appellent la même instance.

Retire la variable. MCP_AUTH_STRATEGY=oauth2 reste accepté pour ne pas punir une configuration correcte, mais il ne sélectionne rien et sera supprimé.

MCP : « MCP_ENABLED=true requires app.auth »

MCP_ENABLED=true requires app.auth to be configured. Both MCP credentials — API
keys and OAuth access tokens — are Better Auth plugins, so without app.auth
nobody can authenticate to /mcp. Either configure app.auth or unset MCP_ENABLED.

Les deux identifiants survivants sont émis par la couche d'authentification : une application sans bloc app.auth ne donne donc à personne un moyen d'entrer. Y monter /mcp laisserait une route soit inaccessible, soit sans garde ; le démarrage s'arrête plutôt. Ajoute un bloc app.auth, ou laisse MCP_ENABLED désactivé.

Toujours bloqué ?

• Lance sovrium validate <config> pour vérifier la configuration seule.
• Un échec non rattrapé affiche Unexpected error: avec un message et un lien vers les tickets. Cette bannière signifie que Sovrium n'avait pas anticipé la défaillance — recopiez le message dans votre signalement.
• Cherche dans la documentation avec ⌘K, ou ouvre un ticket GitHub ou une discussion.

Pages liées

• Dépannage : démarrage et configuration — les erreurs avant que le serveur soit lancé.
• Variables d'environnement — chaque variable lue par Sovrium.
• Durcissement de la sécurité — secrets, rotation et posture de déploiement.
• Intégration MCP — connecter un client MCP de bout en bout.