Oh, c’est toujours derrière un proxy inverse, j’ai juste trouvé un modèle et quelques façons différentes de gérer Discourse. Tout en utilisant toujours la méthode d’installation officielle.
Je vais faire un guide bientôt. Juste au cas où quelqu’un d’autre aurait besoin de l’utiliser ou si j’avais besoin de l’utiliser à nouveau LOL.
Il n’y a qu’un petit problème car mon installation n’utilise pas le SSL letsencrypt. Le lien d’activation par e-mail qui a été envoyé contenait http au lieu de https. Il y a une redirection de tout http vers https mais j’aimerais forcer https depuis le backend afin que tous les liens aient https et non http.
De cette façon, si pour une raison quelconque quelqu’un a accès à ma salle de serveurs. Il ne peut pas simplement brancher un câble Ethernet et voir le trafic clairement. La connexion serait toujours HTTPS et rendrait la vie un peu plus difficile pour l’intrus. J’aime avoir ma chaîne HTTPS complète. Pas WAN HTTPS → Proxy inverse HTTP → backend.
Sinon, ce serait simplement une sécurité de façade.
Confiance zéro, même si je vous connais depuis 10 ans+.
Juste, si vous n’avez aucune confiance à ce point où vous passez en réseau privé, ou si vous ne pouvez pas construire un réseau sécurisé après que le proxy inverse le maintient comme gardien.
N’avez-vous pas remarqué que la plupart des fuites proviennent toujours de l’intérieur. De cette façon, je sais que la sécurité de mon serveur est infaillible et que la seule vulnérabilité serait humaine, et mes employés le comprennent à 100 %.
J’ai quelques utilisateurs cloud de haut profil et si leurs données sortent pour une raison miraculeuse, sachant que la sécurité de mon serveur est infaillible. Je peux alors vérifier les caméras et savoir exactement qui serait la cause de la fuite de données.
Je pense qu’AWS fait quelque chose de similaire, d’après ce que j’ai vu. La vulnérabilité humaine devrait toujours être une priorité. Peu importe la sécurité de votre serveur. Une clé USB et c’est fini.
Parce que si vous ne le faites pas, cela enverra, par exemple, des liens d’e-mail qui pointent vers http plutôt que https, ou des liens vers des images avec http plutôt que https. C’est activé par défaut si Discourse peut dire qu’il s’agit de https ; je ne suis pas tout à fait sûr pourquoi ce n’est pas la valeur par défaut à ce stade, car Discourse ne fonctionne pratiquement pas s’il y a des liens http.
Il ne s’agit pas de la connexion entre le proxy inverse et Discourse, mais des liens que Discourse crée vers lui-même.