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 les trois qui surprennent le plus — deux d'entre eux parce que ce sont des avertissements, pas des échecs, et que la fonctionnalité ne marche tout simplement pas.

Auth : « You are using the default secret »

You are using the default secret. Please set `BETTER_AUTH_SECRET` in your
environment variables or pass `secret` in your auth config.

Une application avec authentification a besoin d'un vrai secret de signature en production. En développement, elle retombe sur un secret de dev intégré et se contente d'un avertissement — c'est pourquoi ce message apparaît en général au déploiement, et non pendant que tu construisais la fonctionnalité.

sovrium secret generate auth   # affiche AUTH_SECRET=<64-hex>

Tant qu'elle n'est pas définie, les sessions sont signées avec une clé identique dans toutes les installations Sovrium — n'importe qui peut en forger une. Traite cet avertissement comme bloquant pour tout déploiement joignable depuis l'extérieur de ta machine.

« 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 : « no token is set »

MCP env validation failed: MCP_AUTH_STRATEGY=token but no
MCP_TOKEN_ADMIN/MEMBER/VIEWER is set. At least one role token must be configured
for clients to authenticate.

Tu as activé le serveur MCP avec l'authentification par jeton sans lui donner de jeton : aucun client ne pourrait jamais s'authentifier. Contrairement aux deux précédents, celui-ci est fatal — le serveur refuse de démarrer plutôt que d'exposer un point d'accès que personne ne peut utiliser.

Fournis au moins un jeton de rôle, chacun de 32 caractères ou plus :

MCP_TOKEN_ADMIN=$(openssl rand -hex 32)

Chaque jeton de rôle accorde les permissions de ce rôle à qui le détient : émets donc le plus restreint qui fonctionne — MCP_TOKEN_VIEWER pour un client en lecture seule. Voir Intégration MCP.

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 — recopie le message dans ton 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.