La invitación de API con el parámetro group_names devuelve 403 para el propietario del grupo a menos que sea administrador

Contribuir Error
,
1

Resumen

Un usuario no administrador que sea propietario de un grupo de Discourse puede invitar correctamente a nuevos miembros con ese grupo asignado a través del diálogo de invitación de la interfaz web. La misma acción realizada a través de la API REST (/invites.json, clave de API de alcance global, Api-Username correcto) devuelve un error 403 invalid_access, pero solo cuando se incluye group_names/group_ids en la carga útil. Esto ocurre independientemente de si group_names se pasa como una cadena simple (p. ej., "group_names": "my-group") o como una matriz (p. ej., "group_names": ["my-group"]); ambos formatos producen el mismo error 403.

Es crucial señalar que conceder al usuario el estado de Moderador no corrige la llamada a la API; solo conceder el estado de Administrador completo lo hace, a pesar de que el estado de Moderador es suficiente para todos los demás escenarios probados (interfaz web, invitación por API sin grupo).

Entorno

  • Versión de Discourse: [completar — página Admin → Upgrade]
  • Tipo de clave de API: Alcance global, Api-Username = el nombre de usuario exacto del usuario de prueba

Pasos para reproducir

  1. Crear un usuario no administrador y no moderador (<userid>), y hacerlo propietario del grupo <group_name>.
  2. En la interfaz web, como <userid>: invitar sin grupo → éxito. Invitar con <group_name> asignado → éxito.
  3. Por API, como <userid> (clave de alcance global, Api-Username=<userid>):
    • POST /invites.json sin group_names → éxito.
    • POST /invites.json con group_names="<group_name>" (formato de cadena) → 403 invalid_access.
    • POST /invites.json con group_names=["<group_name>"] (formato de matriz) → 403 invalid_access (fallo idéntico, se probaron ambos formatos).
  4. Promocionar a <userid> a Moderador. Repetir las llamadas a la API con grupo del paso 3 (ambos formatos) → sigue siendo 403 invalid_access.
  5. Promocionar a <userid> a Administrador. Repetir las llamadas a la API con grupo del paso 3, misma clave, mismas cargas útiles → éxito.

Comportamiento esperado

Dado que la propiedad del grupo por sí sola es un permiso suficiente para que un usuario no de staff asigne ese grupo al invitar a través de la interfaz web, la API —autenticada como el mismo usuario a través de Api-Username— debería respetar el mismo permiso. Como mínimo, el estado de Moderador (que es de staff) no debería comportarse de manera idéntica a la de un usuario no privilegiado aquí; el hecho de que el Moderador falle de manera idéntica a la de un usuario sin rol, y que solo el Administrador tenga éxito, sugiere que la ruta de código de la API comprueba específicamente user.admin? en lugar de la propiedad del grupo o incluso el estado general de staff (user.staff?, que es verdadero para los moderadores).

Comportamiento real

La API devuelve un error 403 para cualquier invitación con grupo (formato de parámetro de cadena o matriz) a menos que el usuario que actúe sea un Administrador completo. La propiedad del grupo (verificado que funciona a través de la interfaz web) y el estado de Moderador/staff (verificado mediante una prueba de promoción directa) son insuficientes para la ruta de la API, a pesar de que cualquiera de los dos es suficiente a través de la interfaz web o para el caso de API sin grupo.

Pregunta para el equipo de Discourse

¿La ruta de código de invitación con grupo autenticada por API requiere explícitamente user.admin?, en lugar de comprobar la propiedad del grupo o user.staff? de la manera en que lo hace la ruta de la interfaz web / autenticada por sesión? De ser así, ¿es esto intencional (una restricción específica de la API no documentada) o es un error donde la comprobación del guardián de la API diverge de la comprobación del guardián de la web para esta acción?

Estoy dispuesto a proporcionar registros completos de solicitudes/respuestas (clave enmascarada) si se solicita.