Eso es exactamente lo que tenía en mente también.
Incluiré el enlace al tema Category Group Review/Moderation, ya que inicialmente me costó encontrarlo buscando.
Siempre me cuesta encontrar Documentation en la categoría Announcements
2 Me gusta
Honestamente, esta es probablemente una buena idea independientemente, los administradores tienen TODOS los derechos (descargar copias de seguridad, ver/cambiar secretos de configuración, ver PII de las personas, acceso a Mensajes Personales, …) y es mejor mantener este círculo reducido.
Hay mucho margen para “privilegios altos” sin ser administradores completos.
2 Me gusta
Muchas gracias a ambos, ¡no sabía que esto era algo aparte!
Gracias por esa aclaración, no sabía que este era el caso. Tienes razón, definitivamente limitaríamos esto de todos modos ahora que lo sé.
He revisado los límites/requisitos de esto y se lo he pasado a mi equipo. Desafortunadamente, parece que todavía tendríamos que alojarlo nosotros mismos. El alojamiento FOSS que ofrecen es muy generoso, simplemente no encajamos en los requisitos.
El mayor infractor son los límites de vistas de página. 50k/mes de vistas de página es probablemente más que suficiente para la mayoría de los proyectos FOSS, pero generamos mucho más tráfico que eso. Nuestro sitio web principal ha recibido 1.87 millones de solicitudes totales de 56.47k visitantes únicos solo en los últimos 7 días. Temo que alcanzaremos fácilmente el límite de vistas de página a este ritmo.
¡Gracias por señalarme esto!
4 Me gusta
Probablemente valdría la pena encontrar una manera de lidiar con esto. Si sabe qué usuarios en su servidor son personal de Discourse (administradores o moderadores), tal vez establezca el campo de correo electrónico SSO para esos usuarios con su correo electrónico real. Cualquiera de sus cuentas de correo electrónico duplicadas obtendría la dirección de correo electrónico falsa.
Hay algunos casos en los que es útil que el personal pueda recibir correos electrónicos de Discourse. El primero con el que probablemente se encontrará es que Discourse proporciona una ruta /u/admin-login para los usuarios del personal. Esa ruta muestra un formulario que acepta una dirección de correo electrónico del personal. Discourse enviará un enlace de inicio de sesión de un solo uso al miembro del personal. Es útil para configurar SSO: si se bloquea accidentalmente fuera del sitio al configurarlo, le permitirá volver a entrar. También es útil si alguna vez hay un problema con su servidor de autenticación.
1 me gusta
Estoy de acuerdo, y es algo en lo que he estado pensando (por razones ajenas a Discourse). El gran problema surge del hecho de que los miembros regulares pueden, y han llegado a ser, personal. Por lo tanto, incluso si exigiéramos correos electrónicos únicos para los usuarios del personal, no podríamos garantizar que los usuarios los tengan, lo que causaría problemas cuando un usuario cuya cuenta tenga un correo electrónico duplicado se convierta en miembro del personal.
Dicho esto, ahora que está claro que DiscourseConnect primero utiliza el ID único para buscar usuarios y que la parte “Discourse utiliza correos electrónicos para mapear usuarios externos a usuarios de Discourse” de la publicación de DiscourseConnect solo se refiere a vincular nuevos usuarios de SSO con cuentas de Discourse existentes, y mi malentendido sobre cómo funciona la indicación de inicio de sesión se ha aclarado, ¿hay algo que realmente nos impida simplemente enviar direcciones de correo electrónico duplicadas tal como están? ¿O esta unicidad se aplica estrictamente?
Sí. Dejé un paso fuera de mi descripción del flujo de inicio de sesión. Discourse primero intentará encontrar al usuario basándose en external_id, luego intentará encontrar al usuario basándose en su email. Si no se encuentra ninguno, Discourse intentará crear al usuario. Así es como sus usuarios se registrarán inicialmente en Discourse. Discourse no permite direcciones de correo electrónico duplicadas, por lo que si se intenta crear un usuario con una dirección de correo electrónico que ya se está utilizando, Discourse generará un error.
Deberá asegurarse de que los correos electrónicos enviados en la carga útil sean únicos por usuario.
Entendido, gracias por la aclaración 
¿es posible actualizar manualmente el correo electrónico de un usuario más tarde? Ahora que el problema del aviso de inicio de sesión se ha resuelto, podría considerar implementar la idea que tuvo mi equipo antes, utilizando correos electrónicos falsos y un servidor SMTP que administramos y que mapea esos correos electrónicos falsos al correo electrónico real de un usuario. Por ejemplo, actualizaríamos el correo electrónico de Discourse de todos a algo como userid@example.com, que se conecta primero a nuestro servidor SMTP y toma el userid para buscar el correo electrónico real del usuario. Sin embargo, esto no estaría listo por algún tiempo, por lo que necesitaríamos actualizar los correos electrónicos de Discourse de los usuarios más tarde si fuera posible.
Sí. Necesitarás habilitar la configuración del sitio auth overrides email para esto. Cuando está habilitada, el correo electrónico de un usuario de Discourse se sincroniza con el correo electrónico que se incluyó en la carga útil de autenticación (la carga útil de DiscourseConnect en tu caso) cada vez que el usuario inicia sesión. Si no está habilitada, el correo electrónico del usuario se establecerá en el correo electrónico de la carga útil de autenticación cuando se cree la cuenta inicialmente, pero no se actualizará en inicios de sesión posteriores.
Suponiendo que auth overrides email está habilitada, también puedes actualizarlo sin requerir que los usuarios inicien sesión realizando una solicitud de API a la ruta sync_sso: Sincronizar datos de usuario de DiscourseConnect con la ruta sync_sso.
También podrías actualizar las direcciones de correo electrónico de los usuarios en masa desde la consola Rails del sitio, pero (creo) hacerlo de esa manera activará el envío de un correo electrónico de confirmación desde Discourse al usuario. Eso no funcionará con direcciones de correo electrónico falsas.
Tal vez podrías simplemente establecer los correos electrónicos en algo significativo para empezar. Una vez que tengas un sitio de Discourse configurado, deberías hacer algunas pruebas para ver qué dominios de correo electrónico acepta Discourse para correos electrónicos falsos. Si mal no recuerdo, creo que @invalid.com es aceptado. No estoy seguro acerca de otros dominios. De tu lado, podrías mapear algo como <userId>@invalid.com a la dirección de correo electrónico real del usuario.
Has sido increíblemente útil, ¡muchas gracias! La solución de la API es lo que tenía en mente, pero saber que puede sincronizarse por sí sola también funciona perfectamente.
Podríamos hacerlo, sí. Primero iba a intentar usar la dirección plus, de esa manera al menos algunos usuarios todavía recibirían correos electrónicos desde el principio. Luego, más tarde, se traduciría a nuestro propio servidor de mapeo SMTP para dar soporte a todos, incluidos aquellos para los que la dirección plus no funcionó.
1 me gusta
@simon @supermathie Han sido increíblemente útiles hasta ahora, espero poder salirme un poco del alcance del hilo y pedir ayuda de seguimiento.
He instalado Discourse en una máquina local para pruebas, usando Install Discourse for development using Docker como guía. No pude encontrar ninguna otra guía sobre cómo configurarlo para pruebas locales. El wiki parece cubrir solo configuraciones de producción, que requieren tener tu dominio/DNS/SMTP ya configurados. No queríamos exponer el foro al público hasta que todo estuviera implementado de nuestro lado, por lo que necesitábamos pruebas locales donde nada de esto fuera requerido.
Lo he puesto en marcha usando esa guía, e implementé el SSO en una instancia local de nuestro sitio, pero me he encontrado con 2 problemas hasta ahora:
- ¿La redirección a
return_sso_urlsolo parece funcionar a medias? En mi caso, la URL eshttp://localhost:3000/session/sso_login. Se redirige correctamente, sin embargo, después de la redirección inicial me envía ahttp://localhost:3000, que simplemente muestra el errorRuntimeError: Discourse no soporta compilar archivos scss/sass a través de Sprockets. El único hilo que pude encontrar sobre este error es Error when building: discourse does not support compiling scss/sass files via sprockets, pero realmente no pareció ir a ninguna parte. El OP no aceptó ninguna solución, y lo único que sucedió fue preguntar sobre los tamaños de RAM y swap (la máquina en la que se está ejecutando tiene 32 GB de RAM y 2 GB de swap. Así que dudo que este sea el problema). - ¿
avatar_force_updateparece no ser respetado? ¿O al menos, no para los usuarios administradores? He habilitadodiscourse connect overrides avataren la configuración del sitio, y en el payload de respuesta del SSO estoy estableciendo tantoavatar_urlcomoavatar_force_update. Pero al iniciar sesión en la cuenta de administrador (que está vinculada a mi cuenta externa) no se muestra mi foto de perfil externa. Puedo ver queexternal_avatar_urlse está estableciendo correctamente al verificar los datos del usuario administrador a través de la API, ¿simplemente no parece estar siendo utilizado en la interfaz de usuario?
Hay una lista de métodos de instalación aquí: Set up a local Discourse Development Environment?. Tengo un sitio de desarrollo que no usa Docker (usando la guía de Ubuntu). Si es posible para ti, creo que obtendrás los mejores resultados con el enfoque que no usa Docker. Una de las razones por las que lo uso es para no tener que lidiar con problemas de red para las solicitudes de API entre Discourse y otras aplicaciones que estoy desarrollando localmente. También es más rápido que Docker.
Debería serlo. Asegúrate de que la aplicación en la que estás generando la carga útil de SSO no esté convirtiendo el valor booleano true a 1. Ese es un problema común. Para solucionarlo, puedes establecer cualquier valor booleano en la carga útil de SSO a las cadenas \"true\" o \"false\". Discourse los interpretará correctamente. Verifica eso primero para ver si es el problema. Podría ser otra cosa. El código que maneja avatar_force_update es algo complejo, pero legible: discourse/app/models/discourse_connect.rb at 187204705323b650d61ed25862eb1a0c733aa63c · discourse/discourse · GitHub.
Edición: Para el problema de los valores booleanos en la carga útil de SSO, supongo que es más exacto decir que en el proceso de generación de la carga útil de SSO, el entorno convertirá los valores booleanos verdadero/falso a cadenas. Discourse espera que las cadenas sean \"true\" o \"false\", otros entornos de programación pueden manejarlos de manera diferente. Por ejemplo:
PHP:
wp> strval(true)
=> string(1) "1"
en contraposición a Ruby:
irb(main):001> true.to_s
=> "true"
Python (no estoy seguro de cómo Discourse maneja esto):
>>> str(True)
'True'
2 Me gusta
Probaré con uno de estos. Gracias por señalarme esa dirección. Sin embargo, eso es bastante contraintuitivo. Típicamente la gente busca la solución Docker como el método “rápido y fácil” para configurar las cosas. Esta es la primera vez que se me recomienda evitar la versión Docker. Aunque todavía queda la pregunta de por qué esto sucede con la versión Docker. Usar otro método de instalación para evitar el problema funciona por ahora, pero no resuelve el problema subyacente.
Definitivamente no se está estableciendo en 1. Estoy trabajando en JavaScript, y el valor booleano true siempre se convertirá en la cadena \"true\":
String(true); // 'true'
(true).toString(); // 'true'
// Esto es lo que mi código está usando realmente
querystring.stringify({
avatar_force_update: true
}); // 'avatar_force_update=true'
Nunca he trabajado con Ruby, así que no estoy seguro de hasta dónde llegaré al investigar esto. Pero a simple vista no veo ningún problema. Sin embargo, he verificado que tanto la configuración relevante en el panel de control de Discourse como en la carga útil SSO están establecidas:
No he probado a cambiar la imagen de una cuenta de usuario estándar de algo que no sea con lo que se creó la cuenta, pero cuando inicié sesión en una cuenta de usuario estándar por primera vez, Discourse descargó el avatar y lo aplicó como se esperaba. ¿La única cuenta que no se actualiza es la cuenta de administrador?
Para ser justos, en PHP casi siempre querrías usar var_export para obtener la representación de cadena “real” de una variable, ya que devuelve el PHP válido necesario para recrear dicha variable:
var_export(true); // true
1 me gusta
Echa un vistazo a la sección DiscourseConnect que se encuentra en la parte inferior de la página de administración del usuario. Hay un botón en el que puedes hacer clic que se expandirá para mostrar los valores de la última carga útil SSO que recibió Discourse.
También puedes encontrar la misma información desde la consola de Rails. Por ejemplo:
>SingleSignOnRecord.last
# o
>SingleSignOnRecord.where(external_id: 2)
Deberías habilitar la configuración del sitio verbose discourse connect logging. Eso añade detalles adicionales a los registros que se generan en Administración / Registros / Registros de errores. Para el problema del avatar, es posible que las entradas de registro relevantes aparezcan como registros de error normales, no como registros de DiscourseConnect.
Posiblemente el problema sea específico de WordPress. Siempre devuelve 1 para true y "1" para la representación de cadena de true.
1 me gusta
Es la carga útil esperada y la URL de la imagen de perfil se muestra correctamente:
La imagen de perfil DEBERÍA ser esta:
Sin embargo, todavía se muestra como:
Que es mi Gravatar:
A menos que esté malinterpretando esta configuración, o a menos que haya algo más que también deba configurar, he habilitado la configuración para anular estas:
También he probado esto en modo incógnito, en diferentes navegadores y borrando la caché del navegador para descartar un problema de caché.
¿Esto está en tu sitio de desarrollo local?
Me pregunto si la carga del avatar falló por alguna razón. Intenta habilitar la configuración del sitio verbose discourse connect logging (registro detallado de discourse connect), luego cierra sesión y vuelve a iniciarla. Debería haber al menos un mensaje en los registros relacionado con el avatar:
Posiblemente habrá otro error relacionado con el fallo de la carga.
En caso de que aún no lo hayas descubierto, esto significa: “debes acceder a través del proxy ember-cli en lugar de directamente desde un navegador”.
Usa bin/ember-cli -u para iniciarlo en modo de desarrollo.
Dupliqué tu situación de avatar:
antes:
carga útil de inicio de sesión:
después:
pero:
Creo que esto es un error donde Discourse establece correctamente la URL del avatar personalizado pero no cambia de Gravatar a la imagen personalizada.
Si creo un nuevo usuario:
funciona de inmediato:
así que sospecho que esto se activa al tener una cuenta con un gravatar configurado antes de usar DiscourseConnect.
2 Me gusta
Logré que los pasos de Ubuntu funcionaran (después de un buen ajuste, ya que el script de instalación estaba en conflicto con paquetes y software que ya tengo instalados). Eso solucionó el error original que tenía, pero el SSO todavía solo funciona a medias. Ahora, en lugar del error scss/sass, el SSO da Account login timed out, please try logging in again. cada vez. Hacer clic en el botón Login por segunda vez mientras se está en esta página de error completa el inicio de sesión. No hubo cambios en el código de mi parte, solo en la forma en que se ejecuta Discourse.
Voy a atribuir todo esto a las peculiaridades de ejecutar esto localmente. Espero que un despliegue en producción no tenga los mismos problemas.
Esto no pareció hacer nada con la versión de Docker. El script salía sin ninguna salida, y realmente no parecía pasar nada en el lado de Discourse. Eso también va en contra de los pasos enumerados en la guía de Docker, lo que se siente extraño. ¿Hay alguna razón por la que esto no se mencione allí?
Me parece extraño que el método de Docker parezca tener estos problemas, y que el consejo oficial sea instalar Discourse de forma nativa (a pesar de que el script de instalación no siempre funciona de inmediato, ya que asume cosas como el uso de bashrc e intentará instalar versiones de paquetes potencialmente conflictivas que ya están instaladas). ¿Debería haber una advertencia sobre los posibles problemas con todas las versiones de alojamiento disponibles? A simple vista, no está claro cuál es la que se debe elegir, y la gente suele asumir que si hay una compilación de Docker disponible, esa debería ser la preferida.
¡Me alegra saber que no soy solo yo! 
Los errores nunca son divertidos, pero me alegra haber ayudado a encontrar este.
Ese podría ser el caso, pero deberías poder hacer que DiscourseConnect funcione localmente sin problemas. ¿Estás accediendo a Discourse en http://localhost:4200? Hay un problema extraño (en mi opinión) por el cual se puede acceder a Discourse en localhost:4200 o 127.0.0.1:4200 en un entorno de desarrollo local. Yo me quedaría con el dominio localhost. Se trata como una sesión diferente a 127.0.0.1.
De todos modos, eso es solo una suposición sobre lo que está sucediendo. Asegúrate de habilitar la configuración de registro detallado y mira los registros para obtener más detalles.
Las instrucciones de instalación deben dejar claro que no necesitas ejecutar el script. Simplemente puedes seguir el script paso a paso para asegurarte de que todas las dependencias estén instaladas.
Sí, lo estoy.
Los que se enlazaron anteriormente no dejan esto claro. Fui a Set up a local Discourse Development Environment? y seleccioné Install Discourse on Ubuntu or Debian for Development ya que estoy ejecutando Ubuntu 22.04.3. Esta página sí dice que no tienes que ejecutar todo el script, pero en texto pequeño después de la parte que instruye a los usuarios a ejecutarlo.
Para mí, esto no estaba claro, ya que al leer las instrucciones de arriba a abajo, uno asumiría naturalmente que tiene que terminar el paso actual antes de continuar. Así que luché contra el script de instalación, instalando solo lo que necesitaba, solo para luego continuar leyendo después de terminar y ver que eso era lo previsto todo el tiempo y que en realidad no tenía que luchar con nada.
Poner esa advertencia después de las instrucciones definitivamente no las deja claras, en mi opinión.
1 me gusta
¿Parece que cree que el nonce es incorrecto? Ahora veo esto en los registros al iniciar sesión:
No se puede verificar la autenticidad del token CSRF. 3:44 pm
Registro detallado de SSO: Iniciado proceso de SSO add_groups: admin: avatar_force_update: avatar_url: bio: card_background_url: confirmed_2fa: email: external_id: failed: groups: locale: locale_force_ 3:44 pm
Registro detallado de SSO: Nonce incorrecto, se generó en una sesión de navegador diferente o ha caducado add_groups: admin: avatar_force_update: true avatar_url: https://pretendo-cdn.b-cdn.net/mii/1424784 3:44 pm
Registro detallado de SSO: Iniciado proceso de SSO add_groups: admin: avatar_force_update: avatar_url: bio: card_background_url: confirmed_2fa: email: external_id: failed: groups: locale: locale_force_ 3:44 pm
Registro detallado de SSO: El usuario inició sesión en PN_Jon add_groups: admin: avatar_force_update: true avatar_url: https://pretendo-cdn.b-cdn.net/mii/1424784406/normal_face.png bio: card_background_url: confirm 3:44 pm
MaxMindDB (/home/jon/discourse/vendor/data/GeoLite2-City.mmdb) no se pudo encontrar: No existe tal archivo o directorio @ rb_sysopen - /home/jon/discourse/vendor/data/GeoLite2-City.mmdb 3:44 pm
MaxMindDB (/home/jon/discourse/vendor/data/GeoLite2-ASN.mmdb) no se pudo encontrar: No existe tal archivo o directorio @ rb_sysopen - /home/jon/discourse/vendor/data/GeoLite2-ASN.mmdb 3:44 pm
Tras una inspección más detallada, parece que se debe a que la redirección de SSO no está utilizando localhost. Me está enviando de vuelta a 127.0.0.1. Si cambio de usar localhost a usar 127.0.0.1 inicialmente, el problema se soluciona.