¡Hola!
Estamos enviando una invitación de Discourse a nuestros usuarios una vez que crean una cuenta en nuestra aplicación. Ya tenemos su nombre y los campos personalizados que necesitamos para nuestra comunidad, pero el usuario tiene que volver a escribirlos en Discourse.
¿Existe alguna manera de que completemos esos campos como parte de su perfil?
¡Gracias!
Creo que lo mejor sería que tu aplicación actúe como el servidor de SSO. Si no deseas eso, entonces tu aplicación puede crear el usuario mediante la API e incluir esa configuración. Puedes averiguar cómo hacerlo con Cómo realizar ingeniería inversa de la API de Discourse.
No queremos crear usuarios mediante la API porque deseamos que el usuario cree su propia contraseña y elija su nombre de usuario. Estuve investigando la posibilidad de crear un usuario en estado provisional con todos los datos, pero parece que esto no es posible a través de la API.
La otra opción que se me ocurre es ampliar las invitaciones para permitir campos personalizados e información del perfil.
¿Quizás un plugin que obtenga los campos de tu aplicación mediante una llamada webhook/API? Podrías configurar el plugin para que haga algo como get yoursite/user/<email_address> y rellene los campos del usuario cuando se actualice el registro. Algo así. SSO sigue pareciendo la mejor solución.
Sí, por favor consulta Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso). Este es exactamente el caso de uso para el inicio de sesión único (SSO).
Con SSO, sin embargo, no necesitarías invitarlos. Simplemente visitarían tu instancia de Discourse y se iniciarían sesión automáticamente si ya han iniciado sesión en tu aplicación. Si aún no han iniciado sesión en tu aplicación, Discourse los redirigirá a tu aplicación para que inicien sesión y luego serán redirigidos automáticamente de nuevo a Discourse.
El caso es que estamos usando Discourse como proveedor de SSO y esto nos ha funcionado bien, pero sí, estoy de acuerdo en que sería más fácil si Discourse consumiera un proveedor de SSO.
@blake Todavía estoy pensando en cómo podemos hacer esto, ya que estamos usando Discourse como nuestro proveedor de SSO. No quiero migrar a otra cosa por el momento porque implicaría mucho más trabajo. ¿Tienes otras ideas? No es un problema si tenemos que escribir código personalizado, pero queremos hacer la menor cantidad de cambios posible en cómo tenemos configurado todo.
¡Gracias!
Solo me confunde tu configuración y estas dos frases, porque entonces en realidad no tienes Single-sign-on, sino double-sign-on.
Si Discourse fuera tu SSO, los nuevos usuarios de tu aplicación deberían redirigirse primero a Discourse para crear una cuenta y luego redirigirse de nuevo a tu aplicación una vez autenticados. Así toda la información estaría en un solo lugar.
Entonces, según mi comprensión actual, convertiría tu aplicación en un proveedor de SSO y haría que Discourse lo consumiera. O redirigiría a los usuarios de tu aplicación para que se registren primero en Discourse y luego regresen a tu aplicación, porque aparentemente así no está configurado actualmente.
De lo contrario, si deseas tener una configuración de dual-sign-on, una vez que se registren en tu aplicación, créalos automáticamente como usuarios en Discourse mediante la API con una contraseña aleatoria que nunca les darás y rellena automáticamente su información de perfil con los datos que proporcionaron en tu aplicación. Luego, envíalos a la página de restablecimiento de contraseña en Discourse para su nueva cuenta en lugar de enviarles una invitación.
Realizamos el registro a través de nuestra aplicación, pero nuestra aplicación no tiene gestión de sesiones. Solo cobramos al usuario y almacenamos su información en nuestra base de datos.
Necesitamos exigir al usuario que cree primero una cuenta, y este es el paso que queremos eliminar porque deseamos hacerlo lo más sencillo posible.
Este es el esfuerzo que no queremos asumir, ya que agregar gestión de sesiones, recuperación de contraseñas, autenticación 2FA y todas las funciones que ofrece Discourse requerirá mucho trabajo.
Esto es lo que no queremos.
Esto es lo que hice inicialmente, pero tenemos que establecer un nombre de usuario aleatorio y eso no es lo que queremos. Aunque funcionará, queremos que el usuario pueda personalizar su cuenta antes de comenzar a usar la comunidad.
Pero sí, supongo que la respuesta sigue siendo usar un proveedor de SSO externo. Seguiré esta ruta y dejaré de pensar en cómo aprovechar Discourse y hacerlo funcionar como queremos.
¡Gracias por la ayuda @blake!
¿O te deshaces de tu aplicación y dejas que Discourse Subscriptions se encargue del dinero?