El endpoint de la API users/by-external/ falla con cabeceras de autorización, funciona sin ellas

Error
1

A partir del 24 de marzo, parece haber habido un cambio en la forma en que la API de Discourse responde a las solicitudes.

No se han realizado cambios en el código de nuestro lado y la Api-Key sigue siendo válida, pero uno de nuestros servicios backend que intenta obtener información del usuario comenzó a fallar al acceder a users/by-external/{id}.json.

Enviamos las cabeceras Api-Key y Api-Username con estas solicitudes, las cuales deberían ser requeridas, según la documentación. Estas solicitudes han estado funcionando bien durante años.

Ahora, todas las solicitudes realizadas a este endpoint fallan con un 403 y el cuerpo de la respuesta:

{
    "errors": [
        "No tiene permiso para ver el recurso solicitado."
    ],
    "error_type": "invalid_access"
}

Esto también sucede si intento solicitar /u/{username}.json.

Sorprendentemente, cuando NO envío las cabeceras, estas solicitudes que, según la documentación, requieren estas cabeceras de autenticación, responden con los datos solicitados, como si estuvieran autenticadas.

También he intentado enviar una Api-Key incorrecta y la respuesta es un mensaje ligeramente diferente:

{
    "errors": [
        "No tiene permiso para ver el recurso solicitado. El nombre de usuario o la clave de la API no son válidos."
    ],
    "error_type": "invalid_access"
}

Esto me dice que la clave está siendo aceptada, pero informa erróneamente que no otorga acceso al recurso, mientras que otorga acceso completo a las solicitudes no autenticadas.

También acabo de probar con una Api-Key nueva con opciones globales / todos los usuarios, y obtengo los mismos resultados.

4 Me gusta
10

Después de trabajar en esto con @Tim_Scaffidi, nos dimos cuenta de que el usuario que se estaba pasando para Api-Username había sido desactivado automáticamente por SiteSetting.invalidate_inactive_admin_email_after_days. Es probable que haya un error relacionado con esta configuración, donde las llamadas API realizadas por un usuario no actualizan la actividad de “inicio de sesión” de ese usuario.

7 Me gusta
15

Volví a investigar para ver si había algún código que debiera cambiarse para mejorar las cosas, pero como el problema solo ocurrió porque se estaba utilizando una clave de API de “Todos los usuarios”, no creo que debamos cambiar nada en cuanto al código. La mejor opción para evitar la desactivación del usuario es utilizar una clave de API de “Usuario único” para que podamos verificar la fecha de última utilización en el registro de la clave de API en lugar de intentar verificar la fecha de última visualización en el registro del usuario.

1 me gusta