Erzwungener Beitrag in eingeschränkter Kategorie

Unterstützung
1

Hallo,

ich nutze Discourse über die API als Backend für eine Community. Es gibt bestimmte Kategorien, die für normale Benutzer eingeschränkt sein sollen, sodass sie keine Themen erstellen oder Titel bearbeiten können. Sie sollten jedoch in der Lage sein, die Threads zu sehen und darauf zu antworten. All dies soll über die API (unter Verwendung eines Admin-Tokens) im Namen dieser Benutzer erfolgen. Gibt es eine Möglichkeit, dies über geeignete Sicherheitsmaßnahmen und API-Aufrufe umzusetzen? Beispielsweise wäre es ausreichend, wenn ich im Namen eines normalen Benutzers (unter Verwendung eines Admin-Schlüssels/eines Admin-Benutzers) einen Beitrag in einer eingeschränkten Kategorie erstellen könnte, aber ich kann diesen Fall in der API-Dokumentation nicht finden.

Vielen Dank!

2

Die API wird für Ihren Anwendungsfall wirklich nicht dokumentiert, da sie vollständig nicht unterstützt wird (ich habe jedoch mindestens einen Kunden, der etwas Ähnliches macht). Wie man die Discourse-API reverse-engineert ist wahrscheinlich das Beste, was Sie bekommen können, sowie discourse/config/routes.rb at main · discourse/discourse · GitHub.

Wenn Sie einen Admin-API-Schlüssel verwenden, werden alle Einschränkungen aufgehoben, sodass Sie das Thema erstellen sollten können. Oder erstellen Sie das Thema vielleicht als Benutzer und verschieben Sie es dann in die Kategorie, in der Sie nicht möchten, dass sie posten können?

3

Danke. Mir ist bekannt, dass Reverse Engineering möglich ist, aber es gibt keinen vergleichbaren Anwendungsfall von der Discourse-Frontend-Seite aus, den man abfangen könnte. Ich meine damit, dass es keine Möglichkeit gibt, als anderer Benutzer ein Thema zu erstellen, selbst wenn ich als Admin eingeloggt bin.

Die vorläufige Lösung, die ich implementiert habe, besteht darin, für die betreffende Kategorie Lese-/Kommentierrechte für alle und Lese-/Kommentier-/Erstellungsrechte für Administratoren festzulegen. Themen werden dann ausschließlich vom „System

4

Ich denke, dass die andere Gruppe, der ich geholfen habe, Benutzer hatte, die sich über SSO (vielleicht?) bei Discourse angemeldet haben, sodass sie in eigenem Namen handelten. Auf diese Weise erhält man alle Benutzerschutzmaßnahmen, die Rails bietet. Alles mit einem einzigen Admin-API-Schlüssel zu erledigen, scheint mir eine Rezeptur für eine Katastrophe zu sein.

Aber ich vermute, dass man, um dein aktuelles Problem zu lösen, das Thema als „adin