Je me prépare à migrer quelques instances Discourse vers un nouvel hébergement. Le plan consiste à mettre l’ancien site en lecture seule, à effectuer une sauvegarde, à la transférer vers le nouvel hébergement et à la restaurer tout en mettant à jour les paramètres DNS (avec un TTL court). Cette procédure est entièrement tirée de guides disponibles ici et ailleurs.
J’ai réalisé quelques simulations en utilisant une astuce avec le fichier /etc/hosts pour simuler la mise à jour DNS (et avec DNS over HTTPS désactivé dans le navigateur également). Jusqu’à présent, tout se passe bien.
Cependant, malgré le fait que je prenne soin de fermer le navigateur sur le site « source », puis de ne l’ouvrir qu’après la migration complète sur le site « destination », il oublie que j’étais connecté.
Évidemment, je ne souhaite pas que tous les membres du site soient déconnectés pendant la migration. Où devrais-je chercher ou qu’est-ce que j’oublie ?
L’utilisateur que je teste actuellement dispose des droits d’administrateur et utilise l’authentification à deux facteurs (2FA). De plus, les conteneurs Discourse sont derrière Nginx qui termine le SSL, ce qui pourrait-il avoir un impact sur le problème ?
Je pense que je vais essayer de créer quelques comptes de test sans 2FA, au cas où cela aurait un lien avec le problème : très peu de membres du site utilisent la 2FA, donc cela pourrait être acceptable si ce sont seulement ces sessions qui sont perdues.
Je vais également vérifier que les serveurs source et de destination sont synchronisés avec NTP, bien que je pense qu’ils ne puissent pas être décalés de plus de quelques secondes l’un par rapport à l’autre.
Autre que cela, je suppose qu’il reste toujours le code source à examiner pour essayer de comprendre ce qui entre dans le jeton d’authentification et pourrait causer un problème…
Comment les cookies de session sont-ils affectés par les « signatures » SSL (surtout lorsque, dans mon cas, l’ancien et le nouveau serveur utilisent les mêmes fichiers de certificat SSL sur le même nom de domaine) ?
Bien que je n’aie aucun problème à m’excuser auprès des membres (), je souhaite vraiment éviter ce scénario car je vois plusieurs effets secondaires négatifs :
Les membres ne se reconnectent plus et sont moins susceptibles de participer au forum à l’avenir.
Les membres oublient leur mot de passe et ont besoin d’aide pour le récupérer.
Les membres oublient leur mot de passe et créent de nouveaux comptes, laissant derrière eux de nombreux « comptes zombies » sur le forum, ainsi que des identités dupliquées perdues ou confuses, sans notes d’utilisateur ni historique de publications, etc.
Le problème SSL fonctionne parfaitement devant Discourse (même avec la modification du fichier hosts), ce qui, si vous y réfléchissez, doit être le cas, sinon les équilibreurs de charge auraient des problèmes. Pour autant que je sache, Discourse n’est même pas conscient du SSL, car il est terminé au niveau de Nginx dans cette configuration.
Je suppose qu’une autre question serait : « Est-il possible de migrer un serveur Discourse vers une nouvelle adresse IP sans déconnecter tout le monde ? » J’avais supposé que c’était possible, mais peut-être que cette hypothèse était erronée…
Les cookies de session sont chiffrés à l’aide d’une clé secrète générée aléatoirement, qui, par défaut, est stockée dans Redis. Les données Redis ne sont pas incluses dans une sauvegarde, de sorte qu’une nouvelle clé secrète est régénérée lorsque vous restaurez le site sur un nouveau serveur.
Vous pouvez définir manuellement la clé secrète en utilisant une variable d’environnement DISCOURSE_SECRET_KEY_BASE dans votre fichier app.yml. Vous pourriez donc essayer quelque chose comme ceci pour préserver les sessions :
Sur votre serveur existant, ouvrez la console et trouvez la clé secrète dans Redis
Ajoutez DISCOURSE_SECRET_KEY_BASE à la section env: de votre app.yml sur l’ancien serveur, en utilisant la valeur trouvée à l’étape (1), puis reconstruisez l’application. En théorie, si tout se passe bien, Discourse utilisera désormais la valeur issue du app.yml et les sessions des utilisateurs seront conservées. Vous pouvez vérifier que la variable d’environnement est bien utilisée en exécutant :
GlobalSetting.secret_key_base
Assurez-vous que le app.yml du nouveau serveur contient la même SECRET_KEY_BASE. Lorsque vous restaurez la sauvegarde, les sessions des utilisateurs devraient être conservées.
Je n’ai pas testé ce flux, donc si vous prévoyez de l’utiliser pour un forum de production, assurez-vous de le tester au préalable !
Note complémentaire : vous ne devriez absolument pas partager la clé secrète entre plusieurs instances de Discourse. La possession de la clé secrète permettrait à quelqu’un de déchiffrer et de modifier son cookie de session sur un site, ce qui pourrait avoir de très graves conséquences en matière de sécurité.
Excellent - je vais essayer cela sur une instance de test. Je verrai si je peux vous faire un retour si cela fonctionne ou non
Bien compris. Je me demande maintenant s’il faudrait soumettre une demande de fonctionnalité pour ajouter une option permettant d’exporter cette clé dans les sauvegardes ? Pour moi, perdre toutes les sessions d’un site semblerait être une « très mauvaise chose », car il y a plusieurs milliers de comptes sur le site. La pratique de la migration a mis en évidence ce problème, mais je suppose que si la machine ou l’instance Docker était perdue pour une raison quelconque, la clé le serait aussi et nous ferions face à la même perte de sessions.
C’est un équilibre délicat entre sécurité et commodité.
Pour l’instant, si quelqu’un parvient à voler une sauvegarde de Discourse, il dispose de toutes les données du forum. Cependant, il ne peut pas se connecter au forum en direct. Les mots de passe sont hachés, les clés API sont hachées et les cookies de session sont chiffrés.
Si nous incluions le secret dans la sauvegarde, toute personne possédant une sauvegarde pourrait accéder au forum en direct et mener des opérations de hameçonnage, de fraude, etc.
Super ! Nous sommes tout à fait ouverts à l’idée d’avoir un sujet ici sur Meta expliquant comment migrer d’une clé secrète Redis vers une clé secrète dans app.yml. Cela pourrait être lié depuis le sujet « déplacer vers un autre serveur ».
À mon humble avis, la sécurité des sauvegardes par défaut devrait également être améliorée. Bien que les mots de passe et les sessions puissent être hachés et protégés, il pourrait y avoir beaucoup d’autres données dans les messages privés, etc., qui devraient rester confidentielles. Notez particulièrement que, sur notre forum communautaire, nous encourageons les gens à utiliser les messages privés pour échanger des coordonnées et organiser des ventes ou des collectes, plutôt que de publier des numéros de téléphone et des adresses dans des espaces publics.
L’approche que j’adopte pour les sauvegardes consiste à accéder à l’instance, à générer une sauvegarde, puis à la chiffrer immédiatement avec une clé publique en utilisant GPG. Cela rend la sauvegarde inutile à toute personne ne disposant pas de la clé privée correspondante, que je stocke hors du serveur et protège par une phrase de passe.
Cela dit, si la clé secrète des sessions ne change pas, elle n’a besoin d’être sauvegardée qu’une seule fois. Une procédure simple suffit donc pour cela — et j’espère que c’est ce que vous avez décrit ci-dessus.
Je vais essayer et voir si je peux créer ce sujet pour vous
Discourse n’offre pas de messages privés ; la fonctionnalité s’appelle Messages Personnels. Cette distinction est très importante, car elle n’implique aucune confidentialité.
Les administrateurs peuvent déjà lire chaque MP sur le site, sauf si le chiffrement est utilisé.
Bonne remarque. Mais cela ne change pas le fait que les membres peuvent utiliser les messages privés pour échanger des informations personnelles ou des éléments qu’ils ne souhaitent pas voir dans le domaine public. Protéger ces données dans la mesure du raisonnable est donc important.
Un peu hors sujet… mais vous pourriez être intéressé par Discourse Encrypt (deprecated) pour des messages vraiment « privés ». Des sauvegardes fuitées ou volées de messages privés chiffrés ne seraient pas lisibles par un attaquant.
(bien que, comme vous l’avez dit, il reste toujours l’hypothèse que les administrateurs soient de confiance)
@david - peux-tu s’il te plaît vérifier le post suivant et le déplacer dans howto si cela te convient ? (Je ne peux pas créer de sujet là-bas, et Akismet vient de masquer le post, il faut donc régler ça aussi )
@david - un grand merci pour avoir résolu cela et pour les conseils, j’espère que cela aidera aussi les autres - c’est certainement un soulagement pour nous de pouvoir migrer et de conserver les sessions
), je souhaite vraiment éviter ce scénario car je vois plusieurs effets secondaires négatifs :
)