Vorabgenehmigung neuer Benutzer, wenn die lokale Anmeldung deaktiviert ist

Wir haben eine private Website, bei der:

  • Lokale Anmeldungen deaktiviert sind (Facebook- und Google-Anmeldungen sind konfiguriert)
  • Mitarbeiter alle neuen Benutzerkonten genehmigen müssen

Wir verfügen über eine große E-Mail-Mailingliste und möchten alle E-Mail-Adressen in dieser Liste „vorab genehmigen“. Wenn eine Person die Website besucht und versucht, sich mit einem Facebook- oder Google-Konto anzumelden, das mit einer E-Mail-Adresse aus unserer Vorabgenehmigungsliste verknüpft ist, muss sie nicht auf die Genehmigung durch einen Mitarbeiter warten und kann die Website sofort nutzen.

Idealerweise wären wir auch in der Lage, die Gruppenmitgliedschaft pro E-Mail vorab zu konfigurieren.

Ist dies möglich? Lösungen, die die Verwendung der Discourse-API erfordern, sind willkommen.

Ich fürchte, das wird überhaupt nicht funktionieren!
Hauptsächlich, weil Einladungen nicht funktionieren, ohne dass lokale Anmeldungen aktiviert sind. Du wirst also wahrscheinlich ein sehr maßgeschneidertes Plugin benötigen, das all dies übernimmt, oder ein externes Authentifizierungssystem, das deine Anforderungen erfüllt.

Willkommen, Steve!

Ich denke, wenn du die Adressen mit einem Import-Skript importierst, wird das Richtige passieren. Du solltest sicherstellen, dass diese Benutzer nicht als aktiv markiert werden, es sei denn, du möchtest riskieren, sie mit Benachrichtigungen und Zusammenfassungen zu überfluten.

Das sollte von der Konsole aus ziemlich einfach sein. Ich denke, es könnte über die API erledigt werden, wenn du irgendwo gehostet bist.

Was bedeutet “Groß”?

“Groß” bedeutet etwa 5.000 – genug, dass wir diese nicht manuell irgendwo in der Benutzeroberfläche eingeben möchten.

@pfaffman, könntest du bitte etwas genauer erläutern, wie ich die Benutzer über die API erstelle? Es scheint, dass das Feld „password

Dass sie kein Passwort erstellen müssen, aber verpflichtet sind, Ihnen ihre bei der Social-Login-Verbindung verwendete E-Mail-Adresse mitzuteilen, ist einfach nicht dasselbe. Sie können weiterhin auf ein Passwort verzichten, wenn sie einen Social Login nutzen. Ich weise mich oft darauf hin, mich mit meinem Gmail-Konto anzumelden (wenn auch seltener als früher), und meine Frau lehnt dies fast immer ab. Außerdem ist die Anmeldung per E-Mail sehr praktisch und bedeutet, dass Sie nie ein Passwort benötigen. Aber ich schweife ab.

Wenn die API ein Passwort erfordert, generieren Sie einfach ein zufälliges. Ein Passwort, das Sie nicht kennen und nicht benötigen, ist praktisch dasselbe wie kein Passwort.

Irgendwann habe ich GitHub - pfaffman/discourse-user-creator: Create an activated user, optionally assigning to group · GitHub erstellt; ich verspreche nicht, dass es funktioniert, aber es sollte Sie ziemlich weit bringen. Sie möchten nicht aktivierte Benutzer erstellen, daher müssen Sie es entsprechend anpassen, aber es sollte ziemlich klar sein, was zu entfernen ist. (Wenn Sie das Problem einfach nur gelöst haben möchten und ein Budget haben, zögern Sie nicht, mich zu kontaktieren.)

Ich muss zugeben, dass mir erst bei genauerer Prüfung aufgefallen ist, dass das Passwortfeld für Benutzer, die E-Mail-Einladungen annehmen, optional ist. Du hast recht damit, dass Benutzer wählen können sollten, ob sie eine andere E-Mail-Adresse verwenden und ein Passwort erstellen möchten. Ich wäre viel zufriedener, wenn die Benutzeroberfläche deutlicher machen würde, dass das Passwort optional ist, insbesondere wenn die soziale Anmeldung auf der Website aktiviert ist. Mit der aktuellen Benutzeroberfläche müsste jemand wirklich nicht wollen, ein Passwort zu erstellen, um festzustellen, dass dies nicht zwingend erforderlich ist – meiner Meinung nach. Ich denke, ich sollte die Ärmel hochkrempeln und einen PR erstellen, um die UX zu verbessern :wink:

Ich habe mir den Beispielcode angesehen, danke! Nur zur Info: Ich musste diesen Hack verwenden, um die entsprechenden API-Aufrufe durchzuführen: Using the API to create a user on an SSO only system - #13 by DylannCordel – selbst dann glaube ich nicht, dass dies den Anwendungsfall abdeckt, den ich im Sinn hatte, da dies eine E-Mail an den Benutzer zur Aktivierung auslöst. Ich hatte gehofft, dies zu vermeiden, um stattdessen eine nahtlose “funktioniert einfach”-Erfahrung zu haben, falls und wenn sie sich später auf der Website anmelden.

Ich habe auch ein wenig mit dieser Lösung herumgespielt: How to manually add user in discourse? - #10 – Ich denke, es würde funktionieren, Benutzerkonten, die ich habe, mit dieser Methode einzufügen, aber letztlich bin ich mir nicht sicher, ob es sich für mich lohnt, das Risiko einzugehen, die Umgebung direkt im Container zu modifizieren, um diese Änderungen vorzunehmen.

Also, alles in allem, denke ich, dass der Arbeitsablauf, den ich mir erhofft habe, nicht wirklich ein unterstützter/erwarteter Arbeitsablauf ist, und ich werde damit leben müssen, bis die Benutzeroberfläche (vielleicht) irgendwann verbessert wird.

Danke an alle!

Du verwechselst hier ein paar verschiedene Dinge.

  • Soziale Anmeldungen umgehen das Passwort, da die Authentifizierung von Facebook, Twitter, Google usw. übernommen wird.

  • Einladungen machen das Passwort vorübergehend optional, aber du musst den Einladungslink erneut aufrufen, um dich „anzumelden

Dieser Ablauf scheint jedoch zu funktionieren:

  1. Senden Sie eine E-Mail-Einladung an einen Benutzer (dies ist nur möglich, wenn die lokale Anmeldung aktiviert ist).
  2. Wenn der Benutzer auf die Einladung klickt, kann er das Passwortfeld leer lassen und wird sofort angemeldet.
  3. Beim nächsten Besuch der Website und bei Bedarf zur Anmeldung kann er sich mit einem sozialen Konto anmelden, das mit dieser E-Mail-Adresse verknüpft ist.

Man kann durchaus sagen, dass dieser Vorgang vielleicht gar nicht funktionieren sollte und mein früherer Kommentar über eine unklare Benutzeroberfläche eigentlich ein Feature und kein Bug ist, der dazu dient, Menschen davon abzuhalten, diesen Workaround zu nutzen. Dennoch scheint es ein akzeptabler Weg für Benutzer zu sein, die per E-Mail eingeladen wurden, aber letztendlich kein Passwort erstellen möchten und stattdessen die Vorteile der sozialen Anmeldung bevorzugen (z. B. das Übertragen ihres Profilbildes).

Ich verstehe durchaus den früheren Punkt, dass einige Benutzer aktiv ein Passwort anstelle einer sozialen Anmeldung wünschen, und ich bin überzeugt, dass ich diese Option für diejenigen, die sie nutzen möchten, nicht deaktivieren sollte. Ich hoffe jedoch immer noch auf einen einfachen und klaren Weg, um Benutzer einzuladen oder einzurichten, die lieber kein Passwort verwenden möchten.

Dieser Pfad ist in Ordnung, aber bedenken Sie bitte, dass der Fall ohne Passwort nur vorübergehend ist, wie bereits zuvor erwähnt.

Der Benutzer müsste also in jedem Fall „etwas

Das ergibt Sinn. Irgendwann muss der Benutzer ein Passwort erstellen oder sein Social-Media-Konto verknüpfen. Danke!

Wenn du dich mit E-Mail (oder sozialen Netzwerken) anmeldest, brauchst du niemals ein Passwort.