Hola, estoy integrando Discourse con un sitio comunitario donde los miembros ya pueden “bloquearse” entre sí. Así que cuando un miembro de mi sitio inicia sesión en Discourse mediante SSO, me gustaría pasar también la lista de external_id de los usuarios bloqueados. Supongo que estos pueden ir simplemente en el campo “Usuarios silenciados” en el lado de Discourse…
Y si no es así, para lograr esta funcionalidad, parece que tendré que configurar un webhook y, cuando reciba un evento user_logged_in desde el webhook, podré usar la API de Discourse para pasar la lista de usuarios silenciados… ¿es correcto? (Y de ser así: ¿dónde está esa llamada en la API? ¡No pude encontrarla!)
Sí, esto suena algo similar a otras extensiones que SSO ya tiene. Es bastante raro necesitar esto, así que estoy indeciso sobre si agregarlo al protocolo o no.
El webhook funcionará; recibirás una llamada al iniciar sesión y luego podrás hacer una segunda llamada a Discourse para sincronizar la lista a través de nuestra API.
Hola Sam, sí, para mi problema inmediato, simplemente responderé al evento del webhook user_logged_in… sin problema. Gracias por eso.
Y entiendo tu punto de vista en cuanto a lo que se puede pasar en el SSO. A medida que continúo integrando profundamente Discourse con mi sitio, estoy comprendiendo mejor cómo ustedes decidieron implementar el SSO. Funciona bien ahora, pero en realidad creo que podría ser interesante consolidar todos los cuadros de verificación de “Anular SSO…” en un solo cuadro de verificación general, algo como “El SSO gestiona todos los atributos del usuario” (o algo así).
La idea sería que, si activo este cuadro de verificación global de SSO, lo único que tendría que mantener consistente es el external_id: prometiendo a Discourse que siempre será único, siempre identificará al mismo usuario y nunca cambiará. Una vez que eso esté en su lugar, podría pasar todos los campos que deseara con la solicitud de SSO y cargar al usuario completamente desde mi base de datos.
sobre si agregarlo al protocolo o no.