Hallo zusammen,
gibt es eine Möglichkeit, den Login zu einem Forum auf eine bestimmte Rolle wie Moderatoren oder Administratoren zu beschränken?
Hintergrund: Ich migriere ein größeres Forum, und obwohl die URL zu diesem Forum der Öffentlichkeit unbekannt ist, möchte ich den Login während der Tests nach der Migration und bis zur finalen Übergabe nur für Moderatoren und Administratoren zulassen.
Ich dachte, ich hätte früher eine entsprechende Option gesehen, kann sie aber jetzt nicht mehr finden.
Du kannst das Forum so einrichten, dass es nur auf Einladung zugänglich ist, bis alles läuft. Sobald du bereit bist, kannst du es auf öffentliche Registrierungen umstellen. Gehe in deinem Dashboard zu Login und setze die Haken, um es nach deinen Wünschen einzurichten. Wenn du bereit bist, gehe zurück und nehme die erforderlichen Änderungen vor.
Das wird nicht funktionieren, sobald Benutzer importiert sind und ihre Konten aktiviert werden.
Ein temporärer Reverse-Proxy würde mit Authentifizierung funktionieren, führt jedoch zu Komplexität.
Ist eine Änderung des DNS-Namens möglich? Wie planen Sie, die Ausfallzeit zu verwalten?
Sie möchten wahrscheinlich alle Benutzer sperren, damit sie keine E-Mails erhalten. Dadurch können sie sich nicht einloggen, selbst wenn sie die Seite zufällig finden.
Falls das nicht ausreicht, könnten Sie die Nginx-Konfiguration im Container so anpassen, dass eine Basic-Authentifizierung erforderlich ist, um auf die Seite zugreifen zu können.
Ich war mir überhaupt nicht bewusst, dass Discourse eigentlich keine rollenbasierten Funktionen bietet. Ich habe es bisher nur in Projekten eingesetzt, bei denen das kein Problem war. Ich dachte, es wäre möglich, den Login darüber einzuschränken.
@JimPas, wie @Stephen richtig sagte, wird das für importierte Benutzer nicht funktionieren.
Der DNS-Name wird für diesen Zeitraum geändert, da das alte Forum weiterhin live bleibt. Wie ich jedoch bereits eingangs sagte, wollte ich zusätzlichen Schutz haben.
Es sieht so aus, als wäre HTTP-Basisauthentifizierung der einzige Weg, zusätzlichen Schutz zu bieten und Benutzer am Einloggen zu hindern. Ich muss prüfen, wie das funktioniert.
Danke, Leute.
Nicht ganz. Sie haben immer den bewährten Fallback, den öffentlichen DNS-Eintrag zu veröffentlichen und für bestimmte Zeiträume einen Hosts-Eintrag zu verwenden. Wenn Sie neu aufbauen, während der öffentliche DNS-Eintrag fehlt, wird Let’s Encrypt beeinträchtigt, ansonsten funktioniert es. Benutzer müssten sowohl den neuen DNS-Namen als auch die IP-Adresse kennen, um darauf zuzugreifen.
Das Deaktivieren von Konten ist eine Option, aber es gibt auch die Möglichkeit, alle E-Mails unter /admin zu deaktivieren, was wahrscheinlich ratsam ist.
Als Gedanken: Sie können den Zugriff auch über eine weitere Ebene steuern, indem Sie Ihr eigenes IdM/SSO implementieren. Mehr Aufwand, aber potenziell enorme Vorteile in anderen Bereichen auf lange Sicht. Es hängt alles davon ab, womit Sie sich wohlfühlen.
Danke für die Nennung der Alternativen, @Stephen.
Ich denke, die Basis-Authentifizierung wäre der direkteste Weg. Die Verwendung lokaler Hosts-Dateien ist für weniger technisch versierte Mitarbeiter/Moderatoren etwas umständlich, und IdM/SSO ist definitiv zu aufwendig für den hoffentlich kurzen Zeitraum, der benötigt wird, um die Grundlagen für die endgültige Migration zu legen. Außerdem sind wir dort nicht besonders sicher, daher könnten wir es vielleicht gar nicht absichern.
Nur um dies zu aktualisieren, glaube ich, dass wir jetzt einen „Nur-Lese-Modus für Mitarbeiter“ haben. Ich bin mir nicht zu 100 % sicher, wie man ihn aktiviert. 
Ich kann keinen Button in der Benutzeroberfläche finden, außer dem normalen „Nur-Lese-Modus für alle“. 
Ich werde mich umsehen.
Wir haben jetzt Anweisungen in einem Leitfaden: