L'invito API con il parametro group_names restituisce 403 per l'utente proprietario del gruppo, a meno che non sia admin

Contribuisci Bug
,
1

Riepilogo

Un utente non amministratore che è proprietario di un gruppo Discourse può invitare con successo nuovi membri assegnandogli quel gruppo tramite la finestra di dialogo di invito dell’interfaccia web. L’azione identica tramite l’API REST (/invites.json, chiave API con ambito globale, Api-Username corretto) restituisce un errore 403 invalid_access — ma solo quando group_names/group_ids è incluso nel payload. In modo critico, concedere all’utente lo stato di Moderatore non risolve la chiamata API — solo la concessione di Amministratore completo lo fa, anche se lo stato di Moderatore è sufficiente per ogni altro scenario testato (interfaccia web, invito API senza gruppo).

Ambiente

  • Versione di Discourse: 2026.7.1
  • Tipo di chiave API: ambito globale, CheriArchives = nome utente esatto dell’utente di test

Passaggi per riprodurre il problema

  1. Crea un utente non amministratore e non moderatore (<userid>), rendilo proprietario del gruppo <group_name>.
  2. Interfaccia web, come <userid>: invita senza gruppo → riesce. Invita assegnando <group_name> → riesce.
  3. API, come <userid> (chiave con ambito globale, Api-Username=<userid>):
    • POST /invites.json senza group_names → riesce.
    • POST /invites.json con group_names=<group_name> (stesso gruppo di cui è proprietario) → 403 invalid_access.
  4. Promuovi <userid> a Moderatore. Ripeti la chiamata API con gruppo del passaggio 3 → ancora 403 invalid_access.
  5. Promuovi <userid> a Amministratore. Ripeti la chiamata API con gruppo del passaggio 3, stessa chiave, stesso payload → riesce.

Comportamento atteso

Poiché la sola proprietà del gruppo è un permesso sufficiente per un utente non staff per assegnare quel gruppo all’invito tramite l’interfaccia web, l’API — autenticata come lo stesso utente tramite Api-Username — dovrebbe rispettare lo stesso permesso. Al minimo, il Moderatore (che è staff) non dovrebbe comportarsi in modo identico a un utente non privilegiato in questo caso; il fatto che il Moderatore fallisca in modo identico a un ruolo assente, e che solo l’Amministratore riesca, suggerisce che il percorso del codice API controlli specificamente user.admin? anziché la proprietà del gruppo o anche lo stato di staff generale (user.staff?, che è vero per i moderatori).

Comportamento effettivo

L’API restituisce 403 per qualsiasi invito con gruppo a meno che l’utente operante non sia un Amministratore completo. La proprietà del gruppo (verificata funzionante tramite interfaccia web) e lo stato di Moderatore/staff (verificato tramite test di promozione diretta) sono entrambi insufficienti per il percorso API, nonostante entrambi siano sufficienti tramite l’interfaccia web o per il caso API senza gruppo.

Domanda per il team di Discourse

Il percorso del codice per l’invito con gruppo autenticato tramite API richiede esplicitamente user.admin?, anziché controllare la proprietà del gruppo o user.staff? come fa il percorso autenticato tramite sessione / interfaccia web? In tal caso, è intenzionale (una restrizione specifica dell’API non documentata) o è un bug in cui il controllo del guardiano dell’API diverge dal controllo del guardiano web per questa azione?

Sono felice di fornire registri completi di richieste/risposte (chiave oscurata) su richiesta.