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 Global, Api-Username corretto) restituisce un errore 403 invalid_access — ma solo quando group_names/group_ids è incluso nel payload. Ciò accade indipendentemente dal fatto che group_names venga passato come stringa semplice (es. "group_names": "my-group") o come array (es. "group_names": ["my-group"]) — entrambi i formati producono lo stesso errore 403.

Fondamentalmente, 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 tutti gli altri scenari testati (interfaccia web, invito API senza gruppo).

Ambiente

  • Versione di Discourse: [da compilare — pagina Admin → Upgrade]
  • Tipo di chiave API: ambito Global, Api-Username = 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>: invito senza gruppo → riuscito. Invito con <group_name> assegnato → riuscito.
  3. API, come <userid> (chiave con ambito Global, Api-Username=<userid>):
    • POST /invites.json senza group_names → riuscito.
    • POST /invites.json con group_names="<group_name>" (formato stringa) → 403 invalid_access.
    • POST /invites.json con group_names=["<group_name>"] (formato array) → 403 invalid_access (stesso errore, testati entrambi i formati).
  4. Promuovi <userid> a Moderatore. Ripeti le chiamate API con gruppo del passaggio 3 (entrambi i formati) → ancora 403 invalid_access.
  5. Promuovi <userid> a Amministratore. Ripeti le chiamate API con gruppo del passaggio 3, stessa chiave, stessi payload → riuscito.

Comportamento atteso

Poiché la proprietà del gruppo da sola è 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 utente senza ruolo, e che solo l’Amministratore riesca, suggerisce che il percorso del codice API controlli specificamente user.admin? piuttosto che 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 (formato parametro stringa o array) a meno che l’utente operante non sia un Amministratore completo. La proprietà del gruppo (verificata come funzionante tramite l’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 Discourse

Il percorso del codice per l’invito con gruppo autenticato via 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 guardian dell’API diverge dal controllo guardian web per questa azione?

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