Staged Users über API erstellen?

[mattdm (Matthew Miller)]

Ich spiele mit dem Gedanken, einen Webhook+API-Bridge-Service zu entwickeln, um gegebene Kategorien auf zwei verschiedenen Discourse-Foren zu verbinden. Die grobe Idee wäre:

1. Ein Webhook auf jedem Server für Topic- und Post-Ereignisse^[1]
2. Ein Listener, der diese aufnimmt und das Ereignis über die API auf dem gegenüberliegenden Server repliziert

• Äh, etwas, um Schleifen zu verhindern, offensichtlich^[2]
• Prüfen, ob auf dem gegenüberliegenden Server ein Benutzer mit derselben E-Mail-Adresse existiert^[3]
• Wenn kein solcher Benutzer existiert, einen gestuften Benutzer erstellen
• Die Benachrichtigungseinstellungen des gestuften Benutzers ändern, damit er keine E-Mail-Benachrichtigungen erhält^[4]
• Den Beitrag unter dem entsprechenden echten oder gestuften Benutzer erstellen oder aktualisieren

4. Wahrscheinlich eine zeitgesteuerte Routine, um Themen durchzugehen und sicherzustellen, dass nichts übersehen wurde, und möglicherweise neu zu ordnen, damit beide Seiten zustimmen

Aus Understanding user statuses, roles, and permissions denke ich, dass gestufte Benutzer im Grunde das tun würden, was wir wollen – wenn jemand später ein Konto mit dieser E-Mail-Adresse erstellen würde, könnte er es „beanspruchen“ und mit all seinen Beiträgen interagieren, als wäre er schon immer da gewesen.

Aber gibt es eine Möglichkeit, einen gestuften Benutzer über die API zu erstellen? Das sehe ich in Discourse API Docs nicht.

---

1. und möglicherweise auch Like- und Solved-Ereignisse, aber nicht im ersten Durchgang ↩︎

2. Ich habe definitiv darüber nachgedacht, bevor ich diese Liste aufgeschrieben habe ↩︎

3. E-Mail-Adressen als Schlüssel verwenden, da Kontosysteme möglicherweise nicht dieselben Benutzernamen haben ↩︎

4. Ich habe irgendwo hier einen Beitrag darüber gesehen, dass dies möglich ist… ↩︎

[Lilly (Lillian Louis)]

@mattdm

Aber gibt es eine Möglichkeit, einen „staged user“ über die API zu erstellen? Ich sehe das nicht in den Discourse API Docs.

---

1. und möglicherweise auch „Like“- und „Solved“-Ereignisse, aber nicht im ersten Durchgang ︎
2. Ich habe definitiv darüber nachgedacht, bevor ich diese Liste geschrieben habe ︎
3. Verwendung von E-Mail-Adressen als Schlüssel, da Kontensysteme möglicherweise nicht dieselben Benutzernamen haben ︎
4. Ich habe irgendwo hier einen Beitrag darüber gesehen, dass dies möglich ist… ︎

Ich bin mir nicht sicher, ob das das ist, was Sie wollen?

Creating a staged user with an API call

Yes, just create a user via the api. They won’t be “staged” at this point since they actually exist. If they ever need to log in, they can just reset their password. This is also possible Here is a rough example of how to create a user, active them, and generate an api key for them. def create_user user = { name: example1, email: "example1@example.com", password: "ZvAmmkcSWQfsPQLBksg7wK59", username: example1, active: "false", approv…

[mattdm (Matthew Miller)]

Nun, irgendwie schon. Wie der OP in diesem Thema sagt, als Antwort darauf…

@dmccann

Ich versuche, die Erstellung eines vollwertigen Benutzerkontos und die Auswahl eines Benutzernamens zu vermeiden. Im Wesentlichen möchte ich das nachbilden, was im E-Mail-Trigger (‘benutzerdefinierte eingehende E-Mail-Adresse’ in den Gruppeneinstellungen) geschieht, wo die E-Mail-Adresse des Absenders ‘zwischengespeichert’ wird, so dass, wenn sie sich registrieren, sie alle Nachrichten beanspruchen können, die in ihrem Namen über den E-Mail-Trigger erstellt wurden.

… und dort lautet die Antwort im Grunde, eine E-Mail einzufügen und den E-Mail-Verarbeitungscode damit umgehen zu lassen. Aber das funktioniert in diesem Fall nicht, weil ich eingreifen und die E-Mail-Benachrichtigungen für den Benutzer deaktivieren muss, bevor der Beitrag erstellt wird.

Es stellt sich heraus, dass wir SSO-Überschreibungen-Benutzername für eine Seite der vorgeschlagenen Brücke aktiviert haben, daher denke ich, dass die Erstellung von etwas wie ‘othersite-user’ ein Workaround sein könnte … aber das wird ohne diese SSO-Einstellung nicht unbedingt funktionieren.

[supermathie (Michael Brown)]

Wenn das Übergeben von staged: true an den Aufruf zum Erstellen eines Admin-Benutzers nicht funktioniert, sind wir offen für einen PR, um dies zu ermöglichen.

(Es ist meiner Meinung nach eine eher Nischenfunktion, die außerhalb Ihres Anwendungsfalls liegt?)

Vielleicht könnten Sie die Route handle_mail verwenden, um eine gefälschte E-Mail als Benutzer zu posten? (Oh, wie @blake vorschlägt)

Dies würde den gestuften Benutzer bei Bedarf und gleichzeitig das Thema erstellen.

[simon]

@mattdm

Die Antwort besteht darin, im Grunde eine E-Mail einzufügen und den E-Mail-Handling-Code damit zu beauftragen.

Mit diesem Ansatz wird es so aussehen, als hätten Benutzer Themen und Antworten per E-Mail erstellt. Gestellte Benutzer können nur Beiträge per E-Mail erstellen. Sie erhalten einen ungültigen Zugriffsfehler, wenn Sie versuchen, einen Nicht-E-Mail-Beitrag für einen gestellten Benutzer über die API zu erstellen.

Etwas am Ansatz des gestellten Benutzers fühlt sich für mich nicht ganz richtig an. Es könnte sich lohnen, Ihre Benutzer zu befragen, ob sie Bedenken haben. Wenn Sie die Erlaubnis Ihrer Benutzer erhalten könnten, könnten Sie einfach aktive, nicht gestellte Benutzer auf der Spiegel-Website erstellen und dann deren Themen und Kommentare über die API posten.

@supermathie

Wenn das Übergeben von staged: true an den Aufruf zum Erstellen von Administratoren nicht funktioniert, vermute ich, dass wir für einen PR offen wären, um dies zu ermöglichen.

Das Übergeben von staged: true erstellt einen gestellten Benutzer. Ich gehe davon aus, dass ein auf diese Weise erstellter Benutzer per E-Mail posten kann. Meine lokale Entwicklungsumgebung ist nicht für den Versand von E-Mails an Discourse konfiguriert, daher kann ich dies im Moment nicht testen.

[pfaffman (Jay Pfaffman)]

Ich wollte Discourse als generischen Formularprozessor zur Bearbeitung von Kontaktformularen verwenden. Ich hasse Kontaktformulare, aber einige Benutzer ziehen es vor, ein Kontaktformular zu verwenden, anstatt eine E-Mail zu senden. Auch wenn ich denke, dass diese Leute schlechte Entscheidungen treffen, möchte ich es ihnen erleichtern, mich zu kontaktieren, damit sie mir Geld geben können.

Es wäre sehr praktisch, eine Nachricht erstellen zu können, die einen gestuften Benutzer erstellt, ohne auf ein anderes System zurückgreifen zu müssen, um das Formular zu verarbeiten und eine E-Mail zu senden.

Ich gehe davon aus, dass ich ein Plugin erstellen muss, um dies zu tun, aber das ist mein Plan.

Dies ist eines der wenigen Dinge, die ich noch herausfinden muss, um WordPress loszuwerden.

@simon

Sie erhalten einen ungültigen Zugriffsfehler, wenn Sie versuchen, einen Nicht-E-Mail-Beitrag für einen gestuften Benutzer über die API zu erstellen.

Vielleicht werde ich also im Plugin den Beitrag so erstellen, als wäre er eine E-Mail. Das ist in einem Plugin vielleicht nicht allzu schwer. Und das wäre wahrscheinlich über eine API möglich.

[nathank (Nathan Kershaw)]

@pfaffman

Es wäre wirklich praktisch, eine Nachricht erstellen zu können, die einen gestuften Benutzer erstellt, ohne auf ein anderes System zurückgreifen zu müssen, um das Formular zu verarbeiten und eine E-Mail zu senden.

Ich denke, Sie könnten einen Wizard ( Custom Wizard Plugin) verwenden, um das ohne allzu große Mühe zu erreichen. Sie können jetzt anonyme Wizards erstellen. Gerne helfe ich Ihnen, wenn nötig!

[simon]

@pfaffman

Also, was ich im Plugin tun werde, ist, den Beitrag so zu erstellen, als wäre er eine E-Mail.

Ja, das funktioniert: Creating a staged user with an API call - #8 by blake.

[pfaffman (Jay Pfaffman)]

Oh! Natürlich. So liefert der Mail-Empfänger E-Mails aus. Ich glaube, ich möchte einen Endpunkt, der beliebige Felder von welchem Formular auch immer akzeptiert, sie in ein Thema einfügt und sie mir liefert. Das würde mich davon abhalten, einen öffentlichen API-Schlüssel zu haben (der nur zum Senden von E-Mails berechtigt ist, es scheint nicht so schlimm zu sein, JavaScript das Formular verarbeiten zu lassen und es dann an den bestehenden Endpunkt zu liefern).