Appearance

Déconnexion du backoffice après un redéploiement (DataProtection) ​

Symptôme ​

Après un docker compose down && up (ou un déploiement CI/CD qui recrée le conteneur), impossible de rester connecté au backoffice : erreur 500 au "getting current user", ou déconnexion immédiate. Les logs montrent :

The antiforgery token could not be decrypted.
 ---> The key {xxxxxxxx-...} was not found in the key ring.
Storing keys in a directory '/root/.aspnet/DataProtection-Keys' that may not be persisted outside of the container.

Cause ​

ASP.NET Core (DataProtection) chiffre les cookies d'authentification et les tokens antiforgery avec un jeu de clefs. Par défaut ces clefs sont stockées dans le conteneur ($HOME/.aspnet/DataProtection-Keys). Quand le conteneur est recréé, les clefs sont perdues : les cookies émis avant ne peuvent plus être déchiffrés, d'où la déconnexion de tous les utilisateurs.

Solution : persister le dossier de clefs via un volume ​

Monter le dossier des clefs sur l'hôte dans le docker-compose.yml :

yaml
    volumes:
      - ./appsettings.json:/app/appsettings.json:ro
      - ./media:/app/wwwroot/media
      - ./logs:/app/umbraco/Logs
      - ./umbraco-data:/app/umbraco/Data
      - ./dp-keys:/root/.aspnet/DataProtection-Keys   # persiste les clefs DataProtection

Puis recréer le conteneur :

sh
sudo docker compose down && sudo docker compose up -d

Les clefs vivent maintenant sur l'hôte (./dp-keys). Le même key ring est réutilisé à chaque recréation du conteneur, donc plus de déconnexion.

Attention au chemin selon l'utilisateur du conteneur ​

Le chemin des clefs dépend de l'utilisateur qui exécute l'app dans le conteneur :

  • Conteneur en root (images .NET 8 classiques) : $HOME=/root, donc /root/.aspnet/DataProtection-Keys
  • Conteneur non-root (images .NET 9/10 chiseled, souvent Umbraco 16/17) : user app, donc /home/app/.aspnet/DataProtection-Keys

Toujours vérifier le vrai chemin dans les logs (source de vérité) :

sh
docker compose logs | grep "Storing keys"

Monter exactement ce dossier. Si le conteneur est non-root, le dossier hôte doit être inscriptible par son UID :

sh
mkdir -p dp-keys && sudo chown 1654:1654 dp-keys   # UID du user 'app'

Vérification ​

  1. Se connecter au backoffice (navigation privée).
  2. sudo docker compose down && sudo docker compose up -d.
  3. Rafraîchir : on reste connecté.

Le warning Storing keys in ... peut subsister (clefs non chiffrées au repos, limite Linux sans DPAPI), mais elles sont désormais persistées, ce qui est l'objectif.

Note ​

Le package Umbraco.Community.DataProtection (stockage des clefs en base de données) est une alternative connue, mais il ne s'est pas appliqué dans notre setup StarterKit v4 : les clefs continuaient d'aller sur le filesystem (/root/.aspnet). Le montage de volume est la solution simple et fiable retenue.

Contributors

The avatar of contributor named as Clément Favre Clément Favre

Changelog