Nos gustaría integrar Discourse en nuestros sistemas existentes, para eliminar la dependencia de nuestro servidor Discord para el soporte. Ya tenemos configurado nuestro propio sistema de cuentas y nos gustaría reutilizarlo si es posible para reducir la fricción. Sin embargo, las direcciones de correo electrónico no son obligatorias para que sean únicas en nuestro caso, solo los nombres de usuario. Parece que Discourse se basa en la suposición de que los correos electrónicos serán globalmente únicos, lo que nos impide integrarnos directamente.
Discourse utiliza correos electrónicos para mapear usuarios externos a usuarios de Discourse
Lo que no funcionaría en nuestro caso, ya que varias cuentas pueden (y lo hacen) usar la misma dirección de correo electrónico.
Luego analizamos Discourse OAuth2 Basic que a primera vista no requería un correo electrónico:
El único atributo obligatorio es id
Sin embargo, más adelante todavía menciona la introducción manual de una dirección de correo electrónico si no la proporciona la fuente oauth:
Noté que omití la ruta del correo electrónico: SoundCloud no proporciona un correo electrónico, por lo que el usuario tendrá que proporcionarlo y verificarlo cuando se registre por primera vez en Discourse.
¿Seguiría siendo viable usar Discourse en nuestro caso? Que los usuarios proporcionen manualmente una dirección de correo electrónico al iniciar sesión en Discourse por primera vez estaría bien en nuestro caso, pero solo si podemos deshabilitar la capacidad de usar una dirección de correo electrónico durante el proceso de inicio de sesión real (requiriendo el uso solo del nombre de usuario y la contraseña), ya que no podemos mapear de manera confiable un correo electrónico a un usuario único. Poder deshabilitar eso del formulario de inicio de sesión por completo reduciría la fricción de nuestro lado, ya que no sería algo que admitiríamos de todos modos, y nos gustaría evitar que los usuarios siquiera intenten hacerlo.
Consideramos esto, pero no estábamos seguros de cómo afectaría el flujo de OAuth o si añadiría fricción al registro/inicio de sesión. Este tipo de cambio sería invisible para el usuario, por lo que no podrían iniciar sesión a menos que introduzcan esta dirección de correo electrónico modificada. Nuestro servidor de cuentas actual tampoco sería consciente de estas modificaciones, por lo que incluso si introdujeran el correo electrónico modificado, no podríamos encontrarlo en nuestros registros.
¿Esto también rompería a los usuarios que ya utilizan alias de correo electrónico, no?
A menos que iniciaran sesión con el nombre de usuario.
Si permitieras inicios de sesión por correo electrónico (lo que creo que no puedes con DiscourseConnect), simplemente funcionaría si se les enviara un enlace por correo electrónico.
Tendrías que hacerlo consciente. Creo que ese sería el primer paso.
Otra opción fea sería permitir que solo el “primer” usuario (como sea que se defina) inicie sesión en Discourse.
Otra solución fea sería obligar a los usuarios de tu sistema a obtener direcciones únicas para cada cuenta.
Bueno, sí. Por supuesto que ese sería el caso, y es a lo que me refiero. Estaba buscando una solución que simplemente prohibiera el inicio de sesión con un correo electrónico, dejando los inicios de sesión con nombre de usuario como el único método. Estoy de acuerdo con romper esencialmente el soporte de correo electrónico por completo (sin notificaciones por correo electrónico, por ejemplo) simplemente dando correos electrónicos totalmente falsos del servidor oauth. Pero eso crea fricción si la capacidad de usar un correo electrónico para iniciar sesión todavía está disponible, ya que los usuarios intentarían hacerlo y fallarían.
Eso esencialmente nos obligaría a rastrear 2 correos electrónicos separados por usuario, lo cual tampoco es deseable y, como mencionó @supermathie, ni siquiera está garantizado que funcione con todos los proveedores, y aún causa fricción, ya que ahora tendríamos que informar a los usuarios sobre esta dirección de correo electrónico específica del foro que deben recordar.
Sí, eso funcionaría técnicamente. Pero por razones obvias, no sería una solución real para usar, ya que bloquearía a todos los demás para que nunca se unieran al foro.
Esto no es algo que podamos hacer por razones técnicas. La más obvia es que ya tenemos usuarios que tienen la misma dirección de correo electrónico que otras cuentas. Pero la más importante es que simplemente no podemos hacer esto. El proyecto en el que buscamos incorporar Discourse es Pretendo Network, un proyecto de emulación de servidores para Nintendo Network. Nintendo permitió que su sistema de cuentas reutilizara direcciones de correo electrónico, por lo que para emular los servidores con precisión, también tenemos que hacerlo. Forzar correos electrónicos únicos simplemente no está en nuestras cartas.
Alguien de mi equipo sugirió que ejecutemos nuestro propio servidor SMTP que maneje el mapeo de los correos electrónicos falsos de Discourse a los correos electrónicos reales de nuestros usuarios, reenviando los correos electrónicos enviados desde Discourse de esa manera. Lo cual funcionaría, pero obviamente conlleva un mayor costo técnico para nosotros y aún no resuelve el problema de deshabilitar el inicio de sesión por correo electrónico y la fricción mencionada anteriormente que viene con nuestro caso.
Parece que podríamos tener que bifurcar Discourse o usar otra solución de foro para hacer lo que necesitamos.
Estoy recordando de memoria, pero puedes usar DiscourseConnect con direcciones de correo electrónico falsas pero únicas. Si los nombres de usuario están garantizados para ser únicos de tu lado, la implementación podría ser bastante simple. La dirección de correo electrónico podría establecerse en algo como nombredeusuario@invalido.com.
Los usuarios iniciarán sesión en tu sistema con el método que estén usando ahora. Tu sistema generará entonces la carga útil SSO con la dirección de correo electrónico falsa.
La desventaja de este enfoque es que necesitarás deshabilitar los correos electrónicos en Discourse. Eso se puede hacer estableciendo la configuración deshabilitar correos electrónicos en sí o en no personal (si los miembros de tu personal tienen direcciones de correo electrónico únicas).
También podrías considerar usar direcciones de correo electrónico basadas en + para usuarios con direcciones de correo electrónico duplicadas. La última vez que comprobé, Discourse consideraba que las direcciones de correo electrónico basadas en + eran únicas. Solo asegúrate de codificar las direcciones de correo electrónico en la URL antes de usarlas en la carga útil de DiscourseConnect. El riesgo aquí es que si los usuarios tienen direcciones de correo electrónico duplicadas y usan un servidor de correo que no admite direcciones de correo electrónico basadas en +, no recibirán correos electrónicos de Discourse, pero permitiría que tus otros usuarios reciban correos electrónicos de Discourse.
Sí, pero solo para un caso particular. Si un usuario ha creado una cuenta de Discourse antes de que el sitio de Discourse haya implementado DiscourseConnect, Discourse intentará asociar a los usuarios existentes con la dirección de correo electrónico que está en la carga útil de DiscourseConnect. Si estás iniciando un nuevo sitio de Discourse, eso no será un problema.
Otro caso en el que he visto surgir el problema de mapeo de correos electrónicos es cuando, debido a algún código defectuoso en el sitio del proveedor de autenticación, los registros SSO en el sitio de Discourse se corrompieron. En ese caso, el sitio pudo eliminar todos los registros SSO en el extremo de Discourse, y luego hacer que Discourse asociara a los usuarios con la dirección de correo electrónico de la carga útil SSO la próxima vez que iniciaran sesión. Discourse luego generó nuevos registros SSO para los usuarios. Esto aún funcionaría con direcciones de correo electrónico falsas.
La lógica con la autenticación de DiscourseConnect es que Discourse primero intenta encontrar al usuario basándose en el campo external_id de la carga útil; si no encuentra un usuario, recurre a intentar encontrar al usuario basándose en el campo email de la carga útil; si todavía no encuentra un usuario, genera un error.
Verifica todo esto antes de implementarlo en un sitio en vivo, pero sé que el enfoque de correo electrónico falso se ha utilizado en sitios de producción para casos en los que las direcciones de correo electrónico reales de los usuarios no se pueden compartir con el sitio de Discourse.
@simon ¡Gracias por la información! Esto empieza a sonar como que estamos avanzando
Esto está bien, y mencioné anteriormente que esta es una solución aceptable para el problema de “todos los correos electrónicos deben ser únicos”. Estoy perfectamente de acuerdo con deshabilitar esencialmente los correos electrónicos en nuestro caso, y usar correos electrónicos falsos fue una solución a la que llegué antes de publicar esto.
Es posible que no haya sido claro originalmente, pero el punto de la publicación era ver si es posible forzar que el aviso de inicio de sesión solo acepte nombres de usuario, ya que actualmente el inicio de sesión se puede hacer con un nombre de usuario o un correo electrónico. Si los inicios de sesión por correo electrónico todavía se muestran como disponibles en el aviso de inicio de sesión en Discourse, entonces nuestros usuarios pueden intentar usar la dirección de correo electrónico de su cuenta existente y encontrarse con un error. Por lo tanto, tendríamos que lidiar con personas que intentan, y fallan, usar su dirección de correo electrónico actual o de alguna manera hacer que el usuario sea consciente de su nueva dirección de correo electrónico específica del foro. Ambas cosas pueden causar confusión y fricción para los usuarios, por lo que idealmente podríamos simplemente restringir el aviso de inicio de sesión para que solo acepte nombres de usuario.
Tener personal con correos electrónicos únicos tampoco está garantizado, así que no querría depender de ello. ¿Esta configuración solo deshabilita el envío de correos electrónicos? ¿O deshabilita el uso de correos electrónicos en general, como lo que busco con el aviso de inicio de sesión?
Revisé la página de DiscourseConnect varias veces y no vi esta opción allí. ¿Hay quizás un lugar mejor para ver este tipo de documentación? No vi ningún enlace a documentación completa en esa publicación, así que asumí que toda la información allí era todo lo que había.
Admitiré que en realidad no he configurado DiscourseConnect yo mismo para revisar la configuración. Esperaba que la documentación fuera suficiente para comprender qué se puede y qué no se puede hacer, para que no tuviéramos que configurar una instancia de prueba completa del foro a menos que supiéramos que íbamos a comprometernos con ella. Pero parece que todavía hay información no fácilmente disponible, ¿a menos que me haya perdido algo obvio?
Esto también se consideró anteriormente en este hilo, pero el problema sigue siendo que tendríamos que lidiar con inicios de sesión por correo electrónico fallidos o informar al usuario sobre esta nueva dirección de correo electrónico del foro. Eliminar esa fricción era mi objetivo principal. Si eso no es posible aquí sin bifurcar Discourse, y la única solución es lidiar con inicios de sesión por correo electrónico fallidos o dar a las personas un nuevo correo electrónico para recordar, entonces podríamos estar mejor con una solución de foro diferente.
Parece que lo entendí mal, eso no está muy claro según la publicación en sí. Sin embargo, mi punto al mencionar eso fue ilustrar la dependencia de que los correos electrónicos sean únicos, lo que seguiría siendo un problema.
Esto DEFINITIVAMENTE no estaba claro solo por la publicación, a menos que me haya perdido algo. ¡Gracias por esa aclaración! Eso suena más en línea con lo que esperaba.
Hasta donde sé, no es posible forzar el aviso de inicio de sesión de Discourse a mostrar solo el campo del nombre de usuario. También te quedarías atascado tratando de averiguar cómo conseguir que los usuarios se registren en primer lugar. Por eso sugiero DiscourseConnect.
Cuando DiscourseConnect está habilitado, se convierte en el único sistema de autenticación para tu sitio de Discourse. Cuando los usuarios hacen clic en el botón de inicio de sesión en Discourse, se les redirige automáticamente a la URL que has añadido a la configuración del sitio discourse_connect_url. Tu sistema de autenticación se encarga a partir de ahí. Eso significa que si tienes un sitio al que los usuarios pueden acceder actualmente con nombre de usuario y contraseñas, seguirán accediendo de esa manera.
Si no es posible añadir código a tu sitio actual, también podrías crear un pequeño sitio web al que los usuarios puedan acceder con nombres de usuario y contraseñas, y luego añadir el código de DiscourseConnect a ese sitio. Sería menos trabajo que bifurcar Discourse.
¡Gracias! Parece que tenía una incomprensión fundamental de DiscourseConnect. Tenía la impresión de que la página de inicio de sesión permanecía en Discourse y simplemente se conectaba al servidor externo. No sabía que el usuario era dirigido a una página de inicio de sesión diferente de nuestra elección.
Mi incomprensión de DiscourseConnect parece haber sido el quid de este problema y de toda la confusión.
Si no te importa que Discourse envíe correos electrónicos para las notificaciones, podrías hacer que tu SSO le dé a Discourse la dirección de correo electrónico game-username@bogus.invalid.
Entonces, podría ser posible que los usuarios agreguen una segunda dirección de correo electrónico real y luego cambien la falsa por la secundaria.
No lo había hecho. Como dije antes, no queríamos pasar por un despliegue de prueba hasta que supiéramos que Discourse era utilizable. Así que en realidad no había probado nada, hasta ahora solo hemos estado leyendo sobre tus características y preguntando aquí cuando las cosas no están claras. Eso es fantástico de escuchar, no sabía que podíamos controlar las cosas hasta ese punto.
Honestamente, parece bastante difícil encontrar documentación real sobre cualquier cosa fuera de la API. Al menos desde la perspectiva de un usuario primerizo.
No hay nada obvio en la página de inicio de Discourse que enlace a ninguna documentación, y todos los enlaces en la página de DiscourseConnect enlazan a páginas no relacionadas o de vuelta a la propia publicación. Intentar buscar “documentación de Discourse” en los motores de búsqueda solo lleva a páginas como Documentation - Discourse Meta, que es solo la categoría del foro para ello, no una página de documentación real, y https://docs.discourse.org/, pero esta es la documentación de la API y no tiene nada sobre características como DiscourseConnect, al parecer.
Intentar encontrar esta información de forma orgánica ha resultado difícil.
¿Hay algún lugar obvio que me haya perdido donde se explique todo esto? Parece que lo más cercano que puedo encontrar es la categoría del foro, ya que hay muchas guías/tutoriales escritos por el personal y similares sobre diversos temas. Pero, ¿reutilizar el foro para documentarse a sí mismo no me pareció correcto? ¿No hay una fuente de documentación dedicada para las características/herramientas de Discourse como la hay para la API de Discourse?
Correcto, eso funcionaría. Como se ha dicho varias veces, usar un correo electrónico falso del proveedor de oauth fue algo que determinamos incluso antes de publicar esto.
Pero eso por sí solo no resuelve el problema de “si un usuario ve en el aviso de inicio de sesión que se aceptan correos electrónicos, intentará usarlos y fallará debido a tener un correo electrónico falso”.
Sin embargo, acabo de tener un malentendido de cómo funciona DiscourseConnect. Tenía la impresión de que el formulario de inicio de sesión todavía estaba en Discourse y que Discourse simplemente se comunicaba con el proveedor de oauth. @simon me ha corregido esto ahora, no sabía que trasladaba físicamente al usuario fuera del sitio a nuestro propio formulario de inicio de sesión. Eso por sí solo resuelve básicamente todos los problemas que tenía. ¡Gracias, de todos modos!
Ninguna de las personas con las que he trabajado ha estado descontenta con el hosting de discourse.org. Si necesitas alojar por tu cuenta por alguna razón, puedes iniciar sesión en https://dashboard.literatecomputing.com/ y unirte al grupo “prueba gratuita” y usar el Dashboard de forma gratuita (si no puedes averiguar cómo unirte al grupo de prueba gratuita, probablemente necesitarás más ayuda de la que estoy dispuesto a dar). Si estás dispuesto a usar Digital Ocean y mailgun, solo necesitas introducir claves API y un nombre de host.
¡Vergonzosamente ni siquiera pensé en esta opción! Ese es un buen punto y probablemente lo haremos para fines de prueba.
Miré sus opciones de alojamiento hoy, ya que sería más fácil que autoalojarlo, pero desafortunadamente está en gran medida fuera de nuestro presupuesto. Tenemos más de 200.000 usuarios, por lo que el plan “Básico” no es una opción. Tenemos más de 5 empleados, por lo que el plan “Estándar” no es una opción. Y como proyecto FOSS, operamos con donaciones y apenas ganamos lo suficiente para mantener las luces encendidas y pagar a un solo desarrollador a tiempo completo, por lo que el plan “Negocios” está muy fuera de nuestro alcance.
Sin embargo, usar la prueba con fines de prueba es una idea fantástica, ¡gracias! De todos modos, ya autoalojamos la mayoría de nuestros servicios, incluso nuestro instancia de Mastodon, por lo que autoalojar Discourse no es un gran obstáculo.
¡Por supuesto! Siempre feliz de ayudar si puedo, aunque solo sea dando alguna opinión. Espero que no haya parecido demasiado negativo, ya que esa no era la intención, para ser claros.
Si te interesa, ofrecemos alojamiento gratuito para algunos proyectos FOSS… tus números de personal son más altos que nuestros límites, pero las personas que toman la decisión podrían dejarlo pasar.
(ten en cuenta que nuestra definición de “personal” aquí es “Administradores” + “Moderadores de todo el sitio”, no “personal de la empresa respectiva” - me interesaría saber cuál era la definición de personal en tu cabeza antes de esto)
¡Gracias! Me había perdido esto en tu página de precios. Acabo de volver a comprobar y está enterrado al final de la página Lo revisaré y hablaré con mi gente.
Nuestra definición de “personal” en este caso cubre 2 roles amplios:
Personas de nuestro equipo de desarrollo principal (como proyecto de código abierto, esto puede fluctuar, ya que las personas pueden ir y venir, pero hemos tenido ~5-10 desarrolladores activos a lo largo de los años en cualquier momento)
Nuestro equipo de moderación (no desarrolladores y miembros de la comunidad que moderan nuestros servicios, como partidas en línea y nuestra implementación de Miiverse, así como nuestro servidor de Discord). Esto también varía.
PODRÍAMOS limitarlo a solo 5 de nuestros desarrolladores, lo que encajaría dentro de esos límites, pero requeriría que decidiéramos quién tiene derechos completos en el foro y quién no. También limitaría el número de personas capaces de moderar los foros (introdujimos un equipo de moderación fuera del equipo de desarrollo para quitar esta carga solo a nosotros en primer lugar).
¡Definitivamente lo discutiré con la gente de mi lado y veremos qué pasa!
Lo revisaré y hablaré con mi gente.