Ich hoffe, jemand kann mir einen Rat geben; ich wäre euch sehr dankbar. Ich erkläre die Situation.
Ich habe Discourse bereits mehrfach auf meiner Domain hostballs[.]com eingerichtet. Jedes Mal wurde www[.]hostballs[.]com ordnungsgemäß auf hostballs[.]com umgeleitet, da das LetsEncrypt-Zertifikat sowohl mit als auch ohne www abgedeckt wird. Das ist das, was ich als Standardverhalten von Discourse in Verbindung mit der LE-Implementierung kenne.
Aktuell richtet meine neue Discourse-Installation SSL für die Non-www-Seite ein (wie in der URL-Konfiguration festgelegt), deckt aber www nicht ab. Das bedeutet, dass Besucher von www[.]hostballs[.]com nicht umgeleitet werden, sondern stattdessen einen SSL-Fehler sehen. Da ich weiß, dass das Standardverhalten davon abweicht und die Discourse-Installation zu stark kontrolliert ist, als dass ich einfach zu Certbot laufen und alles manuell erledigen möchte (das würde regelmäßige Updates doch nicht gerade einfacher machen), bin ich unsicher, welcher Weg der beste ist.
Während ich versuchte, das Problem zu lösen, habe ich in der app.yml die ssl- und LE-Vorlagen sowie die LE-E-Mail-Adresse auskommentiert. Anschließend habe ich die letsencrypt- und ssl-Verzeichnisse aus /shared/standalone entfernt. Ich habe die Site ohne SSL neu aufgebaut, dann diese Optionen in der app.yml wieder aktiviert und erneut neu aufgebaut, um neue SSL-Zertifikate und -Konfigurationen zu generieren. Zwar funktionierte dies, aber das www-Problem wurde dadurch nicht behoben.
Hat jemand anderes eine ähnliche Situation erlebt und eine Lösung gefunden?
Falls die oben genannten Ratschläge zu einschüchternd sind, können Sie auch eine einfache DNS-Weiterleitung einrichten. Die meisten Registrar bieten dies an.
Discourse kann nicht unter mehreren URLs veröffentlicht werden; der Root-Eintrag (ohne www) und der „A“-Eintrag für www sind separate Adressen. Sobald Sie einen FQDN für Ihre Site festgelegt haben, müssen alle zusätzlichen Adressen über eine Weiterleitung behandelt werden.
Wenn Ihnen keiner der bereits vorgeschlagenen Vorschläge gefällt, können Sie stattdessen www.example.com verwenden und http://forcewww.com/ nutzen, um auf die www-Website weiterzuleiten.
Vielen Dank, Freunde. Lassen Sie mich einige Details durchgehen, die vielleicht jemand anderem in Zukunft helfen könnten.
Das begann damit, dass mir ein Benutzer mitteilte, dass www nicht funktionierte und einen Zertifikatsfehler anzeigte. Als ich den von ihm im Berichts-Thread bereitgestellten https-Link direkt aufrufte, trat derselbe Fehler auf. In der Vergangenheit hatte ich bei der Verwendung von www keinen solchen Fehler erlebt, sondern wurde problemlos zur Root-Domain weitergeleitet. Das führte mich zu der Schlussfolgerung, dass meine Installation nach einer kürzlichen Migration irgendwie beschädigt war und sich nicht wie eine neue Discourse-Installation mit den Standardmerkmalen verhielt.
Also installierte ich eine frische Discourse-Installation auf einer neuen Domain, um zu beweisen, dass www standardmäßig funktioniert, wenn die Root-Domain verwendet wird. Ich ging zur Domain, bearbeitete dann die URL in meiner Adressleiste und fügte „www.
Die einfachste Lösung für jemanden, der seine Root-Domain verwendet und möchte, dass www von LE für eine ordnungsgemäße HTTPS-Weiterleitung signiert wird, ohne es unnötig zu verkomplizieren oder einen anderen Webserver zur Verwaltung der Weiterleitung zu verwenden:
Ja, ich sehe keine Möglichkeit, das umzusetzen, ohne dass Updates potenziell Probleme verursachen könnten. Das ist einfach das Schicksal von Leuten, die eigene Domains für Communities nutzen und unnötige Subdomains vermeiden wollen.
Außer man betreibt natürlich einen weiteren Webserver woanders.
Richtig, ich sehe bereits einen Versuch, der durch eine Dateiänderung unterbrochen wurde, wodurch die Art und Weise, wie sie die Datei in app.yml ändern wollten, gestört wurde:
Egal, ob wir eine Datei direkt bearbeiten oder ob app.yml sie danach bearbeitet: Ein Update hat das Potenzial, diese Datei zu ändern und zu stören, wie du sie bearbeitest, unabhängig davon.
Mein Punkt ist, dass jede Änderung an dieser Vorlage sie erneut beschädigen wird. In den letzten Jahren hat nur eine Änderung die PUPS/Hooks-Methode beeinträchtigt: die Einführung der Unterstützung für ECC.