Bonjour.
Nous avons une installation Discourse v2.4.0.beta2 +346 qui était à l’origine accessible à l’adresse include.metaring.com,
en utilisant Apache HTTP Server sur Ubuntu, qui :
- Redirige toutes les requêtes HTTP vers HTTPS
- Gère lui-même le certificat SSL (LetsEncrypt)
- Redirigeait toutes les requêtes via un Proxy utilisant nginx http sock, de sorte que les ports Docker 80 et 443 de Discourse sont désactivés/non utilisés
Nous avons exécuté :
./launcher enter app
rails c
[1] pry(main)> SiteSetting.force_https = true
=> true
Pour être absolument certain que tout était servi en HTTPS (nous avions plusieurs erreurs sinon)
Et tout fonctionnait parfaitement.
Ensuite, nous avons décidé de déplacer l’application (sans toucher à la base de données ni aux autres éléments) sous include.metaring.com/discourse, nous avons donc édité le fichier app.yml comme suit :
DISCOURSE_HOSTNAME: include.metaring.com<—inchangé, identique à avantDISCOURSE_RELATIVE_URL_ROOT: /discourse
Puis, pour être extrêmement sûr, nous avons exécuté :
./launcher stop app
./launcher destroy app
./launcher cleanup
./launcher rebuild app
Bien sûr, nous avons également ajouté dans le fichier de configuration Apache les règles pour ProxyPass correctement de /discourse vers unix:/../../nginx.http.sock|http://localhost/*discourse*
Après cela, l’application était bien sûr en ligne, mais présentait de nombreux problèmes :
-
Tout le contenu statique (plugins, assets, images, javascripts, uploads) n’était pas accessible. Après de longues sessions de débogage et des recherches web infructueuses pour les faire fonctionner, nous avons créé quelques règles de proxy dans Apache pour les tunnelliser vers le chemin racine localhost, sans le préfixe /discourse (par exemple, /discourse/plugins pointe vers → unix:/../../nginx.http.sock|http://localhost/plugins, etc.)
-
Certains chemins /uploads provenaient des pages web sans le préfixe /discourse, nous avons donc dû écrire une autre règle de proxy Apache pour déplacer /uploads/ vers unix:/../../nginx.http.sock|http://localhost/discourse/uploads
-
Maintenant, la chose la plus étrange : lorsque le client envoie des requêtes contenant /uploads/default/ ou /discourse/uploads/default/ (contenu statique), nous devons suivre la solution au point 1 décrite ci-dessus et les rediriger toutes deux vers
http://localhost/uploads/default/(sans le préfixe /discourse), tandis que les autres requêtes /uploads/ ou /discourse/uploads/ qui ne contiennent pas le préfixe /default dans le chemin doivent être redirigées vershttp://localhost/discourse/uploads/(remarquez que sans le chemin default, cela signifie qu’il s’agit d’appels de services web)
Avec toutes ces 9 règles de proxy que nous avons ajoutées, tout fonctionne à nouveau parfaitement, même sous le chemin /discourse. Mais il nous semble extrêmement étrange d’avoir dû écrire tout cela pour faire fonctionner à nouveau l’ensemble.
Faisons-nous quelque chose de mal ?
Existe-t-il une autre méthode intelligente pour gérer cette situation ?
=== ÉDIT ===
Oublié un autre élément qui est peut-être lié :
Lorsque l’utilisateur tente de télécharger une image personnalisée à utiliser comme avatar personnel, le téléchargement réussit et la miniature de l’image s’affiche correctement.
Mais lorsque le bouton Enregistrer les modifications est appuyé et que la page est rechargée, l’avatar revient à l’avatar utilisateur par défaut
En vérifiant le fichier
production.log, il indique que l’erreur est Code 418.Les autres téléchargements d’images fonctionnent bien.
Merci d’avance pour vos réponses et pour votre travail incroyable !