Hallo.
Wir haben eine Discourse-Installation in der Version v2.4.0.beta2 +346, die ursprünglich unter include.metaring.com verfügbar war.
Sie läuft auf einem Apache HTTP Server unter Ubuntu, der:
- Alle HTTP-Anfragen auf HTTPS umleitet
- Das SSL-Zertifikat selbst verwaltet (LetsEncrypt)
- Alle Anfragen über einen Proxy an nginx http sock weiterleitet, sodass die Discourse-Docker-Ports 80 und 443 deaktiviert/unbenutzt sind
Wir haben Folgendes ausgeführt:
./launcher enter app
rails c
[1] pry(main)> SiteSetting.force_https = true
=> true
Um absolut sicherzustellen, dass alles über HTTPS bereitgestellt wird (wir hatten sonst mehrere Fehler).
Und alles funktionierte einwandfrei.
Dann haben wir beschlossen, die Anwendung (ohne die Datenbank oder andere Komponenten zu ändern) unter include.metaring.com/discourse zu verschieben. Wir haben dazu die app.yml-Datei wie folgt bearbeitet:
DISCOURSE_HOSTNAME: include.metaring.com<— Unverändert, wie zuvorDISCOURSE_RELATIVE_URL_ROOT: /discourse
Um dann extrem sicherzugehen, haben wir Folgendes ausgeführt:
./launcher stop app
./launcher destroy app
./launcher cleanup
./launcher rebuild app
Natürlich haben wir auch in der Apache-Konfigurationsdatei die Regeln eingefügt, um ProxyPass korrekt von /discourse zu unix:/../../nginx.http.sock|http://localhost/*discourse* weiterzuleiten.
Danach war die Anwendung zwar wieder online, hatte jedoch zahlreiche Probleme:
-
Alle statischen Inhalte (Plugins, Assets, Bilder, JavaScript, Uploads) waren nicht verfügbar. Nach langen Debug-Sitzungen und erfolglosen Websuchen, um sie zum Laufen zu bringen, haben wir einige Proxy-Regeln in Apache erstellt, um sie zum Root-Pfad localhost zu tunneln, ohne das /discourse-Präfix (z. B. zeigt /discourse/plugins auf > unix:/../../nginx.http.sock|http://localhost/plugins und so weiter).
-
Einige /uploads-Pfade wurden von Webseiten ohne das /discourse-Präfix geladen, sodass wir eine weitere Apache-Proxy-Regel schreiben mussten, die von /uploads/ auf unix:/../../nginx.http.sock|http://localhost/discourse/uploads umleitet.
-
Jetzt das Seltsamste: Wenn der Client Anfragen mit /uploads/default/ oder /discourse/uploads/default/ (statischer Inhalt) sendet, müssen wir die Lösung aus Punkt 1 befolgen und beide auf
http://localhost/uploads/default/umleiten (ohne das /discourse-Präfix), während andere /uploads/- oder /discourse/uploads/-Anfragen, die kein /default-Präfix im Pfad enthalten, aufhttp://localhost/discourse/uploads/umgeleitet werden müssen (beachten Sie, dass das Fehlen des default-Pfadteils bedeutet, dass es sich um Webdienstaufrufe handelt).
Mit all diesen 9 Proxy-Regeln funktioniert nun wieder alles einwandfrei, auch unter dem Pfad /discourse. Aber es erscheint uns extrem seltsam, dass wir all dies schreiben mussten, damit alles wieder funktioniert.
Machen wir etwas falsch?
Gibt es eine intelligentere Methode, um diese Situation zu handhaben?
=== EDIT ===
Ich habe noch etwas vergessen, das vielleicht damit zusammenhängt:
Wenn ein Benutzer versucht, ein benutzerdefiniertes Bild als persönliches Avatar hochzuladen, läuft der Upload erfolgreich durch, und die Miniaturansicht des Bildes wird korrekt angezeigt.
Aber wenn der Button Änderungen speichern gedrückt wird und die Seite neu geladen wird, kehrt das Avatar zum Standard-Avatar des Benutzers zurück
.
Bei der Prüfung der Datei production.log zeigt sich, dass der Fehler Code 418 ist.
Andere Bild-Uploads funktionieren einwandfrei.
Vielen Dank im Voraus für Ihre Antworten und für Ihre großartige Arbeit!