Was fehlt mir hier? Ein Benutzer hat sich gerade zum ersten Mal über WordPress SSO angemeldet. Ich habe es so konfiguriert, dass Genehmigungen erforderlich sind. Sollte diese Option hier nicht erscheinen? Ich habe keine Ahnung, wie ich diesen Benutzer genehmigen soll 
Ich habe zwar die Benachrichtigung im Admin-Menü, dass ein Benutzer auf Genehmigung wartet.
Ich kann dieses Problem reproduzieren, wenn ich sowohl SSO als auch die Site-Einstellung „Benutzer müssen freigegeben werden“ aktiviere. Um den Benutzer freizugeben, klicken Sie auf seinen Benutzernamen im Prüfungseintrag:
Dadurch werden Sie zur Admin-Seite des Benutzers weitergeleitet:
Im Abschnitt „Berechtigungen“ der Admin-Seite des Benutzers klicken Sie auf die Schaltfläche „Konto aktivieren“, falls das Konto des Benutzers noch nicht aktiviert ist:
Klicken Sie dann auf die Schaltfläche „Freigeben“:
Dadurch sollte der Benutzer freigegeben und die Benachrichtigung aus Ihrer Prüfungswarteschlange entfernt werden.
Cool. Das ist erledigt, vielen Dank. Ist das also beabsichtigt? Ich bin mir nicht sicher, wie das Konzept der Aktivierung hier passt. Muss ich jedes Mal sowohl aktivieren als auch genehmigen?
Ich denke, dass sowohl SSO als auch „Benutzer müssen genehmigt werden
Vielen Dank für die hervorragende Antwort, @simon. Ich habe dies früher nicht erwähnt, da es lediglich auf einer Erinnerung beruhte (die in meinem Fall immer verdächtig ist). Aber…
Ich hatte gerade einen weiteren Benutzer angemeldet, und sofort stand mir die Genehmigungsoption zur Verfügung, d. h. es war kein Durchlaufen der Aktivierungsphase erforderlich.
Das bleibt für mich also ziemlich verwirrend. Ich habe keine Konfigurationsänderung vorgenommen, die erklären könnte, warum der Prozess bei den beiden neuesten Neulingen unterschiedlich war. Die Verwirrung herrscht vor…
Ich werde Sie informieren, falls ich mehr herausfinde.
Nochmals vielen Dank.
Ich dachte, das sei nicht erlaubt. Der SSO-Host ist für die Verwaltung der Benutzer verantwortlich. Meines Wissens nach müssen Sie, wenn Sie möchten, dass bestimmte Benutzer mit SSO-Konten keinen Zugriff auf Discourse haben, dies über Gruppen regeln oder den Login zu Discourse auf irgendeine Weise verweigern.
Obwohl es etwas seltsam ist, dass wir einige Benutzer sowohl aktivieren als auch genehmigen müssen, nachdem sie sich angemeldet haben, scheint es zu funktionieren. Mit unseren aktuellen Einstellungen muss der Administrator die Anfragen jedes Benutzers nach dem ersten Anmeldeversuch genehmigen. Das ist in Ordnung (sozusagen – siehe unten), sodass die beiden Einstellungen (SSO verwenden und Benutzer genehmigen) akzeptabel erscheinen.
Trotzdem ist es bedauerlich und ein echtes Problem, dass man eine Gruppe von Benutzern nicht im Voraus genehmigen kann, bevor diese ihren ersten Anmeldeversuch unternehmen. Das bedeutet, dass Benutzer warten müssen, bevor sie sich anmelden können, obwohl wir (die Administratoren) im Voraus genau wissen, wer sie sind.
Ich vermute, dass @simon mit seiner Einschätzung recht hat, dass dies aus Sicht von Discourse ein Randfall ist. Allerdings ist es bei WooCommerce-Seiten, die sowohl reguläre Produkte als auch Mitgliedschaften verkaufen, ziemlich üblich. Ich befinde mich in genau dieser Situation, und das ist ein weit verbreitetes Szenario. Daher sind meine Benutzer in zwei (sich teilweise überschneidende) logische Gruppen unterteilt: Kunden und Mitglieder. Ich möchte in der Lage sein, die Liste der Mitglieder im Voraus zu genehmigen, damit sie nicht auf eine Genehmigung warten müssen. Ich werde dies eventuell später automatisieren, aber das muss nach dem Start meines Forums am 1. September erfolgen, was schade ist.
Aha! Du möchtest WooCommerce so konfigurieren, dass es diese Gruppen in Discourse verwaltet, anstatt die Benutzer manuell in Discourse zu bearbeiten. Es gibt einige Themen dazu. Dafür ist etwas benutzerdefinierter Code erforderlich, und es stehen Beispiele zur Verfügung. Als Orientierung: Für eine solche Aufgabe berechne ich in der Regel zwischen 1.000 und 1.500 US-Dollar.
Danke @pfaffman. Ich kann das mit etwas Zeit wahrscheinlich selbst erledigen und habe mich bereits informiert. Für den Launch werde ich die Erwartung setzen, dass eine Genehmigung erforderlich ist, und diese einfach schnell bearbeiten. Nach dem Launch werde ich prüfen, ob ich dies irgendwie automatisieren kann.
Eine Klarstellung zu meinen Erwartungen an die vollständig automatisierte Lösung:
Ich möchte eine Lösung vermeiden, bei der Nicht-Mitglieder sich zwar einloggen können, aber dann blockiert werden, weil sie beispielsweise nicht in einer mit Mitgliedern verknüpften Gruppe sind. Stattdessen möchte ich, dass sich Nicht-Mitglieder gar nicht erst einloggen können, vorzugsweise mit der Möglichkeit, sie auf eine Seite umzuleiten, auf der ich den Grund erläutern kann.
Anders ausgedrückt: „Einloggen blockieren, wenn man kein Mitglied ist“ ist vorzuziehen gegenüber „Einloggen erlauben, aber dann den Zugriff auf Ressourcen blockieren“.
Nochmals vielen Dank.
@simon Ich habe mir gerade ein paar Minuten Zeit genommen, um nach möglichen Lösungen für diese Herausforderung zu suchen – und bin dabei auf dieser Seite auf dich gestoßen 
WP Discourse – WordPress plugin | WordPress.org. Ich habe also eine konkretere Frage zu diesem Plugin an dich.
Mein Unternehmen dreht sich um WordPress und WooCommerce, und bei allen meinen Integrationen werden dort, wo es möglich ist, Tags zur Verwaltung von Benutzern verwendet. WP Fusion ist das Bindeglied, das all dies zusammenführt, aber im Kern bedeutet das: Alle meine Benutzer (ob Kunden, Mitglieder usw.) haben Tags.
Vor diesem Hintergrund würde ich gerne in der Lage sein, eine eigene Funktion auf der WordPress-Seite zu schreiben, die eine bestimmte Logik implementiert (in meinem Fall so einfach wie das Prüfen eines Tags beim Benutzer) und die Anmeldung ablehnt, wenn diese Bedingung nicht erfüllt ist.
Weißt du spontan, ob es einen Hook gibt, den ich nutzen könnte, um diese Logik umzusetzen? Das wäre eine großartige Lösung und würde die Anmeldung weiterhin ganz in der Verantwortung von WordPress lassen.
Vielen Dank.
Ja, dieses Thema beschreibt, wie man das umsetzt, was du suchst: How to prevent some WP users from being able to login to Discourse. Der zweite Beitrag im Thema enthält zwei Beispiel-Funktionen, die du verwenden kannst. Du musst den Code bereitstellen, um den Kommentar /* Some condition that returns true if the user doesn't meet the membership requirement */ im Codebeispiel zu ersetzen.
Fantastisch!! Ich glaube, ich habe das Thema früher falsch verstanden, als ich es durchgesehen habe, aber es sieht genau so aus, wie ich es brauche. Wenn die Umsetzung und Tests abgeschlossen sind (berühmte letzte Worte!), dann bin ich bestens gerüstet!
Vielen Dank.
Das habe ich mir schon gedacht. . . und . . .
Hab ich’s doch gesagt! 
Freut mich, dass du gut auf dem Weg bist, das zu klären.
Tatsächlich. Entschuldige bitte, dass ich das übersehen habe, @pfaffman, und danke für deine Hilfe. Ich mache mich jetzt daran, einen gespiegelten Discourse-VPS einzurichten, der mit meiner gespiegelten Website kommuniziert, und hoffe, bei gutem Verlauf, dass dies bald einsatzbereit ist.
