Veo este mensaje cuando intento activar Discourse_id en mi sistema de prueba (3.6.0.beta2-latest):
enable_discourse_id: Debes configurar las credenciales de Discourse ID ('discourse_id_client_id' y 'discourse_id_client_secret') antes de habilitar esta configuración.
Utilizo un servidor Oauth local para OIDC aquí (keycloak). ¿Quizás los dos métodos están interfiriendo entre sí?
No creo que interfiera con OIDC, pero si tu instancia no está disponible en Internet, el registro de ID no funcionará. El proveedor de identidad de Discourse ID tiene un mecanismo de verificación implementado para las instancias de Discourse que inician el proceso de registro.
La instancia de prueba está en línea en forum2.netzwissen.de
Veo el mismo mensaje en 2 instancias, ninguna de las cuales tiene una conexión OAuth diferente.
He movido esto a un tema aparte… ¿ves algún error en /logs en tu instancia? Debería mostrar más detalles allí sobre lo que no funciona internamente durante el proceso de registro.
Me gustaría entenderlo un poco más desde el lado técnico.
En mis instancias, utilizo la autenticación OIDC con un proveedor de identidad externo (Keycloak 26). Discourse ID se ve muy similar; es solo un servidor IDP diferente alojado por Discourse.org. Y los mensajes de error (falta el ID de cliente y el secreto) también recuerdan al flujo OAuth clásico. ¿Significa esto que Discourse ID se activará como una ruta de autenticación de IDP adicional? Porque solo entonces sería útil para mi caso de uso. ???
solo este, pero con relativa regularidad para que no tenga nada que ver con el tema.
Mensaje (2 copias reportadas)
Sidekiq está consumiendo demasiada memoria (usando: 503.02M) para 'rpg-foren-app', reiniciando
Backtrace
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:130:in block in warn' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:231:in block in dispatch’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:231:in each' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:231:in dispatch’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:130:in warn' /var/www/discourse/lib/demon/sidekiq.rb:59:in block in rss_memory_check’
/var/www/discourse/lib/demon/sidekiq.rb:53:in each' /var/www/discourse/lib/demon/sidekiq.rb:53:in rss_memory_check’
config/unicorn.conf.rb:132:in `block (2 levels) in reload
'
Sí, correcto, Discourse ID es otro IDP.
@Tealk el error de sidekiq no está relacionado. ¿Puedes compartir el hash del commit de tu instancia, por favor?
3.5.1 (c96aeda334)
Ok. Entonces necesitaría un ID de cliente en su IDP (para el flujo de acceso público) o un ID de cliente y un secreto de cliente (para el flujo de acceso confidencial). Otra opción: añadir Discourse ID como un intermediario de identidad externo al IDP local. Para ambas variantes se requeriría un poco más de información 
…
Sí, cada instancia de Discourse se registra (en segundo plano) y configura un ID y secreto de cliente.
Ahora que veo tu instancia, veo errores http/https. Para que ID funcione, el sitio debe estar bajo https. Este es probablemente tu problema.
@Tealk asegúrate de que tu sitio también funcione correctamente en https.
No sabría qué podría mejorar:
¿Discourse ID ya funciona en foros que usan la rama estable? Pensé que la función solo se agregaría después del lanzamiento en agosto.
Ah, de hecho, si estás en el canal stable, @Tealk, tendrás que esperar al próximo lanzamiento estable para que Discourse ID esté disponible para ti.
Tenga en cuenta también que DiscourseConnect es una característica separada.
Entonces, eso es confuso en la página de novedades. ¿Sería posible añadir a partir de qué versión se incluye una función?
Ese es un buen punto. Ahora he actualizado el feed de Novedades para incluir solo este elemento en instancias que no están en estable (y que tienen el commit en latest que desbloquea el ID de Discourse). Si actualizas tu feed de Novedades, ya no deberías ver este elemento en tu instancia en estable.
Ya tengo la configuración en la Configuración, ¿debería estar disponible la configuración antes de implementarla?
El ajuste del sitio enable_discourse_id no debería estar presente para ti. (Asegúrate de no confundirlo con enable_discourse_connect, eso es otra cosa).
Ahora que veo tu instancia, veo errores http/https. Para que ID funcione, el sitio debe estar bajo https. Este es probablemente tu problema.
… interesante, pero no entiendo por qué. Quizás tenemos una brecha conceptual aquí: los contenedores de Discourse se encuentran detrás de un acelerador SSL, solo accesibles a través de https. Pero eso es para la conexión estándar que viene desde el “exterior” hacia el “interior”. En el caso de uso de OAuth, el contenedor de Discourse inicia la conexión desde el “interior” hacia el IDP, que está en el “exterior”. No veo ninguna opción para configurar esta conexión al ID de Discourse y forzarla a ser “https”.
Si comparo esto con la configuración clásica de OIDC utilizada para la configuración de OAuth con mi propio IDP: allí tenemos una configuración de “Documento de descubrimiento de OpenID Connect”
https://....realms/[realm-name]/.well-known/openid-configuration
Creo que necesitamos algo similar para el ID de Discourse para evitar problemas con conexiones https faltantes. PD. Mi instancia de prueba tiene 3.6.0.beta2-latest, Commits · discourse/discourse · GitHub
