Existe-t-il un moyen pour le back-end de transformer tous les liens partiels dans les publications (example.com) en liens https (https://www.example.com) ??
Car il semble qu’ils soient transformés en liens http://, ce qui entraîne toutes sortes de problèmes lorsque les requêtes sortantes http://example.com échouent pour de nombreux utilisateurs qui cliquent sur le lien depuis la publication.
(Ou, vérifier l’adresse cible générée et corriger le protocole pour y accéder ?)
Merci, première question, désolé si c’est une répétition, mais je ne trouve rien de concis à ce sujet.
mitch
Non, s’il vous plaît. Il existe de nombreux sites qui utilisent HTTP, car ils n’ont tout simplement pas besoin de SSL.
S’agirait-il d’un autre travail occasionnel pour rechercher et remplacer ? Ou est-ce que je comprends tout mal encore une fois ?
crise de panique irrationnelle
De plus, je m’inquiète d’une situation limite où Discourse utilise son propre VPS et devant lui se trouve un autre VPS avec un proxy inverse. Ceux-ci communiqueront souvent sans SSL.
Mais c’est une situation totalement différente, n’est-ce pas ? Mais je commence à être un peu nerveux chaque fois qu’il y a quelque chose par défaut qui peut changer mes abréviations familières…
Je pense que vous avez tort de dire que ces sites n’ont pas besoin de https. Il n’y a aucune excuse pour ne pas sécuriser votre site maintenant.
Mais il semble que j’aie tort de penser que cela devrait être une demande de fonctionnalité. Le navigateur plutôt que discourse devrait gérer l’obligation de passer en https.
Je suis presque sûr que les navigateurs modernes privilégient le HTTPS par rapport au HTTP par défaut.
De plus, de nombreux sites web côté serveur redirigeront vers HTTPS ou utiliseront l’en-tête HSTS.
Je ne pense pas avoir tort quand on parle de réalité.
Le besoin de sécuriser les connexions entre les serveurs à l’aide de SSL lorsque les données ne contiennent rien qui doive être sécurisé mérite un autre sujet. Mais c’est totalement hors sujet ici.
Mais dire aux utilisateurs que désolé, vous ne pouvez pas lier parce que le tiers n’utilise pas le port 443 est une mauvaise idée. Ce n’est pas le travail de l’administrateur ni même de Discourse de dire ce que quelqu’un devrait ou doit faire.
Oui, s’il est là. Et certains routeurs/modems domestiques sont configurés pour n’utiliser que https et c’est vraiment ennuyeux. Parce que tous les sites ne suivent pas la volonté de Google d’utiliser SSL partout et en partie parce que tant de plateformes servent de vieux liens en utilisant http et ces boîtes stupides ne peuvent pas réécrire l’URL.
Donc, avant toute discussion sur les fonctionnalités, il devrait y avoir un autre méta-sujet : est-il de la responsabilité de la plateforme de forum de forcer l’utilisation de SSL pour les liens sortants.
Après cela, la solution technique est raisonnablement facile, je pense — mais encore une fois, je ne suis pas un développeur.
Mais revenons au sujet.
Donc, la recherche et le remplacement ne sont pas une solution aiguë ? Mais je ne comprends pas maintenant… encore… le vrai problème est-il que Discourse forme automatiquement des liens si une URL simple est donnée ? Si oui, alors je recule un peu et oui, automatiquement il devrait y avoir https — mais cela doit être modifiable.
Donc avec cela (traduit en Ruby si je me souviens bien), le back-end de Discourse pourrait savoir si la cible d’un lien partiel donné dans un post est https ou http, puis (avec une préférence pour https) ouvrir le bon lien cible pour l’utilisateur ?