Kurze Frage: Gibt es eine Möglichkeit, Discourse intern, nur in meinem Netzwerk, nicht über das Internet, zu nutzen?
Nehmen wir an, meine Domain zu Hause heißt testlabs.local. Ich möchte, dass alle Benutzer in dieser Domain auf Discourse zugreifen können. Ich kann über Port 80 darauf zugreifen, aber wenn ich mein Konto registriere, lege ich einen Benutzernamen und ein Passwort fest und wenn ich fortfahre, erhalte ich eine 404 Nginx-Meldung, die Seite ist leer. Seltsamerweise, obwohl ein Fehler auftritt, erhalte ich immer noch die E-Mail, aber wenn ich auf den Link klicke, erhalte ich erneut einen 404-Fehler.
Kann dies also intern so genutzt werden, wie ich es möchte?
Oder darf es nur extern verwendet werden?
Wenn ja, gibt es Anleitungen, um dies intern einzurichten, da ich nur die Cloud-Anleitung sehe?
In der YAML-Datei habe ich meine SMTP-Einstellungen eingerichtet, ich kann sie empfangen. Ich bin mir bei den Feldern für SMTP-Benutzername und -Passwort nicht sicher. Ich kommentiere diese einfach aus, muss das eingerichtet werden? Wenn ja, warum erhalte ich immer noch E-Mails ohne diese Einrichtung?
Ich möchte einfach kein E-Mail-Passwort im Klartext eingeben.
Jede dieser Optionen ermöglicht es Ihnen, Discourse über http://localhost:4200/ zu verwenden. Diese Optionen verwenden alle MailHog, um SMTP zu testen, ohne tatsächlich E-Mails zu versenden.
Update: Ich habe die Frage noch einmal gelesen und sehe, dass Sie anderen Leuten die Nutzung ermöglichen möchten. Ich weiß nicht, ob diese Antwort wirklich hilft.
Discourse funktioniert größtenteils nicht ohne https, was in einem lokalen Netzwerk schwierig zu konfigurieren ist. Sie könnten sich Anleitungen ansehen, die einen Reverse-Proxy beinhalten, aber dies ist keine unterstützte Konfiguration.
Vielen Dank für deine Antwort, ja, ich möchte auch, dass andere Leute es benutzen können. Ich möchte nur klarstellen, dass diese anderen Leute Teil meines lokalen Netzwerks sind, alle werden im Haus darauf zugreifen, kein öffentlicher Zugriff darauf.
Würde es funktionieren, nur auf Einladung und Anmeldung erforderlich zu aktivieren, um Discourse im Internet bereitzustellen, aber einzuschränken, wer es sehen kann? Oder vielleicht Benutzer müssen genehmigt werden (vielleicht mit automatische Genehmigung von E-Mail-Domains) verwenden, um nur Benutzern in Ihrer Organisation den Beitritt zu ermöglichen?
Ich schätze, die Frage ist, welches Problem Sie lösen wollen?
Vielen Dank für deine Antwort. Ich habe es derzeit auf einer Red Hat-Distribution intern in meiner Domäne eingerichtet, nur für den internen Gebrauch. Ich werde damit herumspielen. Was genau meinst du, wenn du sagst, dass es ohne HTTPS nicht funktioniert? Ist es also nur für die externe Nutzung konzipiert, die nur über das öffentliche Internet zugänglich ist?
Könntest du bitte mehr über den Reverse-Proxy-Leitfaden erläutern? Ich verstehe nicht, was du mit “join at guides” meinst.
Derzeit ruhen wir das Produkt nur aus, wir möchten es als internes Forum für unser Unternehmen nutzen.
Für Entwickler und IT, um Beiträge zu veröffentlichen und miteinander zu interagieren. Wir wollen es nur intern, kein öffentlicher Zugang.
Das ist die Lösung, auf die sie sich festgelegt haben. Ich kann das nicht kontrollieren.
Ich denke, die Einstellung Benutzer müssen genehmigt werden erfüllt diese Anforderung effektiv. Viele „interne“ Tools (Slack, Google Suite, Microsoft Office 360, GitHub Enterprise usw.) werden im Internet gehostet, sind aber auf die Benutzer beschränkt, die der Kundenadministrator genehmigt.
Wenn die Platzierung in einem internen Netzwerk eine IT-Anforderung ist, sollten diese auch bei der Einrichtung des Netzwerks für Discourse helfen können.
Ich verstehe, ich frage, wie der Prozess aussieht, damit es nur für den internen Zugriff funktioniert? Es gibt keine Einrichtungsanleitung dafür, und Benutzer sagen, dass es ohne https nicht gut funktioniert.
Ich habe gerade ein lokales Netzwerk in meinem Labor eingerichtet und werde es testen, aber aus früheren Tests hat es intern nicht funktioniert. Ich werde es noch einmal versuchen.
Ich meine, dass ein Großteil des Frontend-Codes davon ausgeht, dass Sie https verwenden. Ich meine, dass die Standardinstallation davon ausgeht, dass Ihre Website ein Zertifikat von Let’s Encrypt erhalten kann.
Hier ist einer. Damit dies funktioniert, müssen Sie Apache mit einem gültigen Zertifikat einrichten und es dann als Reverse-Proxy für Discourse verwenden.
Es ist keine unterstützte Einrichtung. Wenn sich hinter einer Firewall/NAT zu befinden eine Voraussetzung ist, dann ist es die Kosten dieser Voraussetzung, dass jemand, der weiß, wie man einen internen Reverse-Proxy mit einem gültigen Zertifikat einrichtet, einen der Leitfäden wie den oben genannten befolgen kann.
Das ist eine nettere Art zu sagen, was ich gesagt habe.
Sie haben dort IT-Leute. Sie können Zertifikate erstellen, da sie ohnehin Webserver in Ihrem Intranet verwenden. Das einzige Problem ist, ein Zertifikat zu erhalten, das von Browsern zugelassen wird.
