Generar clave API de usuario sin aprobación del usuario

Desarrollador
1

Estoy usando Discourse headless y puedo obtener información del usuario usando la clave API de administrador, pero se recomendó generar una API de usuario para cada usuario. Así que estoy intentando usar ese método en su lugar, pero no quiero que el usuario tenga que navegar a una nueva interfaz de usuario para “aprobar” la API que estoy creando para ellos.

Por lo tanto, mi solución es enviar programáticamente la confirmación. Desde una solicitud GET a ‘/user-api-key/new’, puedo extraer los datos del elemento ‘form’, pero no puedo enviar una solicitud POST a ‘/user-api-key/’ porque obtendré un error CSRF.

He deshabilitado la protección CSRF para Discourse Connect, pero ¿hay alguna otra para api-key?
SiteSetting.discourse_connect_csrf_protection

Si no es así, no usaré las claves API de usuario hasta que pueda crearlas sin la interrupción de la interfaz de usuario.

¡Gracias de antemano!

Aparentemente, existió una solución que podría funcionar en versiones anteriores, pero no veo ninguna versión actualizada de esto:

1 me gusta
2

Quizás estamos construyendo lo mismo :slight_smile: aunque el mío es solo parcialmente headless.

Sospecho que no lo hay, y que es por diseño.

He estado pensando lo mismo, pero creo que en mi caso estará bien, no estoy tratando de ocultar Discourse.

Una cosa a tener en cuenta con las claves API de usuario frente a las claves API de todos los usuarios de administrador es que, por defecto, se les aplican límites de tasa diferentes: Available settings for global rate limits and throttling.

Límite de tasa de API de usuario:
DISCOURSE_MAX_USER_API_REQS_PER_MINUTE: por defecto 20
DISCOURSE_MAX_USER_API_REQS_PER_DAY: por defecto 2880

Límite de tasa de API de administrador:
DISCOURSE_MAX_ADMIN_API_REQS_PER_MINUTE: 60

Si tu aplicación se conecta a un sitio de Discourse autoalojado, es probable que puedas anular el límite de tasa de la API de administrador. Si tu aplicación se conecta a instancias de Discourse alojadas, los límites de tasa de la API de usuario ofrecen mucha más flexibilidad. Con el límite de tasa de la API de administrador, terminas teniendo que poner todas las solicitudes en una cola con límite de tasa.

Editar: en lugar de usar la Especificación de claves API de usuario para generar las claves, puedes usar una clave API de administrador para generar claves API de usuario. Eso evita el problema de que los usuarios tengan que aprobar la aplicación.

Ten en cuenta que la clave publicada a continuación es para mi dominio localhost, por lo que no hay riesgo en publicarla.

parámetros de clave sin escapar: {key:description:sally} {key:username:sally} {key:scopes:[scope_id:topics:write]} {key:scopes:[key:write]} {key:scopes:[name:write]} {key:scopes:[params:[topic_id]]} {key:scopes:[urls:[/posts (POST)]]} {key:scopes:[selected:true]}

❯ curl -X POST \"http://localhost:4200/admin/api/keys\" \
      -H \"Api-Key: $api_key\" \
      -H \"Api-Username: system\" \
      -H \"Content-Type: application/json\" \
      -d $json
{\"key\":{\"id\":29,\"key\":\"f5c6307b51dd2882bde525dc9775fe7504b55c93fa40177b650f9e6b77a9d25b\",\"truncated_key\":\"f5c6\",\"description\":\"sally\",\"last_used_at\":null,\"created_at\":\"2024-06-02T00:44:19.944Z\",\"updated_at\":\"2024-06-02T00:44:19.944Z\",\"revoked_at\":null,\"user\":{\"id\":3,\"username\":\"sally\",\"avatar_template\":\"/user_avatar/127.0.0.1/sally/{size}/58_2.png\"},\"api_key_scopes\":[{\"resource\":\"topics\",\"action\":\"write\",\"parameters\":[\"topic_id\"],\"urls\":[\"/posts (POST)\"],\"allowed_parameters\":{},\"key\":\"write\"}]}}

En cualquier caso, te quedas con una clave API que debe ser gestionada de alguna manera. Supongo que cifrada y guardada en una base de datos.

5 Me gusta
3

¿Estás usando React en tu frontend? Estoy abierto a encontrar una manera de colaborar para reducir la redundancia y aumentar la confiabilidad del código. Creo que la autenticación a través de SSO fue la parte más difícil. Así que, espero que de aquí en adelante todo vaya sobre ruedas.

4

Sí, es una aplicación Remix/React Router. Así que React en el frontend, Node en el backend.

He estado trabajando con eso durante años. Envíame un mensaje aquí si tienes alguna pregunta al respecto.

Estoy tratando de hacer algo que funcione bien con los límites de tasa del sitio alojado de Discourse. Esa ha sido la parte complicada. Las claves API de usuario parecían una forma posible de lidiar con eso, pero también hay un límite de tasa por dirección IP, así que vuelvo a usar una sola clave API y pongo en cola todas las solicitudes API.

1 me gusta
5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.