API-Invite mit group_names-Parameter liefert 403 für Gruppenbesitzer, sofern sie kein Admin sind

Beitragen Fehler
,
1

Zusammenfassung

Ein Nicht-Administrator-Benutzer, der Inhaber einer Discourse-Gruppe ist, kann über das Einladungsdialogfenster der Web-Oberfläche erfolgreich neue Mitglieder mit dieser zugewiesenen Gruppe einladen. Die identische Aktion über die REST-API (/invites.json, API-Schlüssel mit globalem Geltungsbereich, korrektes Api-Username) liefert einen 403-Fehler invalid_access – aber nur, wenn group_names/group_ids in der Nutzlast enthalten ist. Entscheidend ist, dass die Vergabe des Moderator-Status den API-Aufruf nicht behebt – nur die Vergabe von vollen Admin-Rechten funktioniert, obwohl Moderator für alle anderen getesteten Szenarien (Web-Oberfläche, API-Einladung ohne Gruppe) ausreicht.

Umgebung

  • Discourse-Version: 2026.7.1
  • Art des API-Schlüssels: Globaler Geltungsbereich, CheriArchives = der exakte Benutzername des Testbenutzers

Schritte zur Reproduktion

  1. Erstelle einen Nicht-Administrator- und Nicht-Moderator-Benutzer (<userid>) und mache ihn zum Inhaber der Gruppe <group_name>.
  2. Web-Oberfläche, als <userid>: Einladung ohne Gruppe → erfolgreich. Einladung mit zugewiesener <group_name> → erfolgreich.
  3. API, als <userid> (Schlüssel mit globalem Geltungsbereich, Api-Username=<userid>):
    • POST /invites.json ohne group_names → erfolgreich.
    • POST /invites.json mit group_names=<group_name> (dieselbe Gruppe, deren Inhaber er ist) → 403 invalid_access.
  4. Erhöhe <userid> zum Moderator. Wiederhole den gruppenspezifischen API-Aufruf aus Schritt 3 → weiterhin 403 invalid_access.
  5. Erhöhe <userid> zum Admin. Wiederhole den gruppenspezifischen API-Aufruf aus Schritt 3, gleicher Schlüssel, gleiche Nutzlast → erfolgreich.

Erwartetes Verhalten

Da die Gruppenzugehörigkeit allein ausreicht, damit ein Nicht-Personal-Benutzer diese Gruppe bei einer Einladung über die Web-Oberfläche zuweist, sollte die API – authentifiziert als derselbe Benutzer über Api-Username – dieselbe Berechtigung akzeptieren. Mindestens sollte Moderator (der zum Personal gehört) sich hier nicht identisch wie ein Benutzer ohne Berechtigungen verhalten; die Tatsache, dass Moderator identisch wie eine Rolle ohne Berechtigungen fehlschlägt und nur Admin erfolgreich ist, deutet darauf hin, dass der API-Codepfad spezifisch user.admin? prüft, anstatt die Gruppenzugehörigkeit oder sogar den allgemeinen Personalstatus (user.staff?, der für Moderatoren wahr ist) zu überprüfen.

Tatsächliches Verhalten

Die API liefert einen 403-Fehler für jede gruppenspezifische Einladung, es sei denn, der handelnde Benutzer ist ein vollberechtigter Admin. Die Gruppenzugehörigkeit (funktionsfähig über die Web-Oberfläche verifiziert) und der Moderator-/Personalstatus (durch direkten Erhöhungstest verifiziert) reichen beide für den API-Pfad nicht aus, obwohl einer von beiden über die Web-Oberfläche oder für den Fall der API ohne Gruppe ausreichen würde.

Frage an das Discourse-Team

Erfordert der API-authentifizierte Codepfad für Einladungen mit Gruppe explizit user.admin?, anstatt die Gruppenzugehörigkeit oder user.staff? zu überprüfen, wie es der Web-Oberflächen-/Sitzungs-authentifizierte Pfad tut? Falls ja, ist dies beabsichtigt (nicht dokumentierte, API-spezifische Einschränkung) oder ein Fehler, bei dem die API-Guardian-Prüfung sich von der Web-Guardian-Prüfung für diese Aktion unterscheidet?

Gerne stelle ich vollständige Anfrage-/Antwort-Protokolle (Schlüssel anonymisiert) auf Anfrage bereit.