Notre site doit fonctionner à la fois en HTTP et en HTTPS. Nous devons sécuriser le cookie (_forum_session). Actuellement, il possède uniquement le drapeau HttpOnly, mais il manque le drapeau Secure. Comment pouvons-nous configurer cela pour inclure également le drapeau Secure ?
La tendance sur le web depuis de nombreuses années est d’utiliser uniquement HTTPS.
Cela posait problème jusqu’à ce que des organisations comme Let’s Encrypt (LE) commencent à offrir des certificats SSL gratuitement et à fournir un mécanisme robuste pour les gérer.
Lorsque LE (certbot) est utilisé pour configurer les certificats sur votre site, il configure à la fois HTTP et HTTPS, et le trafic HTTP est automatiquement entièrement redirigé vers HTTPS.
Bien sûr, vous pouvez trouver un moyen d’exécuter Discourse uniquement en HTTP, mais cela ne sera pas pris en charge, sauf dans le cadre du développement de Discourse ; car sans HTTPS, toutes les informations de connexion des utilisateurs, y compris les mots de passe, seraient transmises de manière non chiffrée sur le réseau. Cela N’EST PAS pris en charge en production.
Imaginez cela ainsi : HTTPS, c’est comme porter une ceinture de sécurité dans une voiture. Les personnes qui souhaitent conduire sans ceinture le font à leurs propres risques ; ainsi, les constructeurs automobiles ne produiront pas de voitures sans ceintures de sécurité.
Il en va de même pour Discourse. Discourse est conçu pour fonctionner en toute sécurité en production ; ainsi, la version prise en charge de Discourse en production est HTTPS.
Merci @neounix. Notre problème est que le certificat HTTPS est géré par le load balancer et que seul le port 80 est ouvert entre Discourse et le load balancer. Nous avons essayé de rediriger HTTP vers HTTPS sans succès. Pourriez-vous s’il vous plaît partager avec moi le fichier de configuration des cookies dans Discourse ?
Si c’est le cas, il est très probable que vous ayez un proxy inverse devant votre équilibreur de charge (ou intégré à celui-ci).
Laissez-moi vous expliquer.
Le proxy inverse (avec équilibreur de charge si vous en avez un) communique avec Discourse en backend via HTTP.
Vous avez donc raison : Discourse ne communique qu’en HTTP, mais uniquement avec le proxy inverse, pas directement avec le monde extérieur.
Voici comment cela fonctionne :
UTILISATEURS WEB <-----> HTTPS <-----> PROXY INVERSE <----> HTTP <----> ÉQUILIBREUR DE CHARGE <----> DISCOURSE (DOCKER)
Ainsi, vous pouvez exposer votre conteneur Docker Discourse sur le port 80 (HTTP uniquement), comme vous l’avez mentionné.
Cependant, côté site web accessible au public, vous avez besoin d’un proxy inverse qui relaie les requêtes HTTPS vers le backend en HTTP.
Votre proxy inverse (avec équilibreur de charge), s’il est correctement configuré, s’assurera que les cookies et les en-têtes HTTP sont transmis correctement dans les deux sens.
J’espère que cela vous aide.
Si vous avez d’autres questions, n’hésitez pas à les poser.
Notez que si vous pouvez nous fournir les détails techniques exacts de votre architecture, cela nous facilitera grandement la tâche pour vous aider ; nous n’avons pas d’application de boule de cristal à notre disposition