Discourse OpenID Connect (OIDC)

[david (David Taylor)]

Hola @balazsorban44, gracias por el recordatorio. He hecho una primera revisión de la PR. Si el autor no tiene tiempo para trabajar en esas cosas, entonces es probable que podamos asumirlas. Estoy de acuerdo en que tener soporte PKCE sería bueno.

Sin embargo, vale la pena señalar: no creo que Discourse sea vulnerable a los ataques de “intercepción de códigos de autorización” que PKCE protege. La autenticación de Discourse siempre ocurre en el navegador a través de https, y no utiliza esquemas de URL personalizados a nivel del sistema operativo que pueden ser interceptados por otras aplicaciones.

Pero, por supuesto, no hay ningún daño en agregar la capa adicional de seguridad

[balazsorban44 (Balázs Orbán)]

No necesariamente preocupado por la seguridad.

Abordé los comentarios aquí, manteniendo el historial del contribuyente original para darle crédito: feat: PKCE support by balazsorban44 · Pull Request #86 · discourse/discourse-openid-connect · GitHub

Encantado de terminar el swing

[Lander_Noterman]

@swt2c

Al usar este plugin con AWS Cognito, para cerrar sesión, Cognito requiere pasar un parámetro client_id a la URL de cierre de sesión. Por lo que he podido averiguar, no hay forma de añadir parámetros de consulta adicionales a la URL de cierre de sesión, ¿es correcto? Si no es así, ¿es posible añadir esta capacidad?

¿Has encontrado una solución para esto?

[swt2c (Scott Talbert)]

Desafortunadamente, no.

[Lander_Noterman]

@swt2c Lo he implementado en el plugin añadiendo

  params << ["client_id", "<my-client-id>"]
  params << ["logout_uri", post_logout_redirect] if post_logout_redirect

después de la línea params << ["post_logout_redirect_uri", post_logout_redirect] if post_logout_redirect en plugin.rb.

¡Sería genial obtener soporte oficial para esto!

[david (David Taylor)]

@balazsorban44 ¡Gracias por encargarte de esto! Acabo de fusionar la PR, así que ahora tenemos soporte PKCE opcional en el plugin

[hhf.technology]

Hola Chris:
¿Cómo integraste Authentik con este plugin? Cualquier información útil nos ayudaría. Llevamos un par de semanas luchando para que funcione correctamente.

[chrisblech (Christoph Blechschmitt)]

Hmm, no puedo recordar algo especial. ¿Cuál es tu problema exactamente? ¿Quieres compartir algunas capturas de pantalla de tu configuración (quizás por mensaje privado)?

[hhf.technology]

gracias por responder chris. claro. me pondré en contacto contigo más adelante esta semana cuando mi equipo de desarrollo esté disponible, que estaba trabajando en authentik. los principales problemas son con el flujo y el outpost.

[davispuh (Dāvis)]

Tengo un problema interesante, antes de desplegar públicamente quiero probar que todo funciona, así que mi proveedor OIDC está alojado localmente (subred privada) y no es accesible desde Internet.
Desafortunadamente, esto falla porque Discourse no permite conectarse a IPs privadas.
oidc.example.org se resuelve a una IP privada.

Registro OIDC: Obteniendo documento de descubrimiento desde https://oidc.example.org/application/o/discourse/.well-known/openid-configuration
Registro OIDC: La obtención del documento de descubrimiento generó un error Faraday::ConnectionFailed FinalDestination: todas las IPs resueltas fueron desautorizadas
Registro OIDC: El documento de descubrimiento es

---

(oidc) Fase de solicitud iniciada.
(oidc) ¡Fallo de autenticación! openid_connect_discovery_error: OmniAuth::OpenIDConnect::DiscoveryError, el documento de descubrimiento falta

Creo que debido a que openid_connect_discovery_document solo puede ser cambiado por el Administrador, debería ser confiable y permitir incluso IPs privadas.

lib/final_destination/ssrf_detector.rb

[david (David Taylor)]

Hay una configuración del sitio llamada ‘allowed_internal_hosts’. Si agregas el nombre de host interno a esa lista, las solicitudes a él serán permitidas a través del Detector SSRF.

@davispuh

Creo que debido a que openid_connect_discovery_document solo puede ser cambiado por el Administrador, debería ser confiable y permitir incluso IPs privadas.

En los servicios de alojamiento compartido (como el alojamiento oficial de discourse.org), los administradores no son confiables para realizar solicitudes dentro del entorno de alojamiento, por lo que esta protección existe por defecto.

[Cesare_Caoduro]

Disculpa, pero no estoy seguro de poder seguir la instrucción para instalar el plugin. Estoy ejecutando Discourse en mi entorno local de Docker, y realmente no puedo encontrar un app.yml para añadir la configuración.
Puede ser una pregunta tonta, pero ¿hay alguna guía para instalarlo en un entorno de desarrollo local?

[NateDhaliwal]

Para un entorno de desarrollo de Docker, ¿intenta buscar en /var/discourse/containers/app.yml?
Sin embargo, para instalaciones de desarrollo que no sean de Docker, consulte aquí:

Install plugins in your non-Docker development environment

(This guide only covers non-docker dev install. For Docker dev see Install Discourse for development using Docker) If you’ve followed the instructions to set up your local discourse, you can install a plugin locally: Stop your local server if it’s running. Download the plugin repo and save it your /plugins folder. Alternatively, you can use a symlink. If the plugin includes migrations (you’ll see them in db/migrate), run them with: LOAD_PLUGINS=1 bundle exec rake db:migrate fro…

[Cesare_Caoduro]

El problema es que no encuentro una carpeta de contenedores.

[NateDhaliwal]

Asumiendo que seguiste esta guía, ¿quizás seguir esta publicación para instalar plugins?

[zabin]

Hola.\nAñadí este plugin y funciona bien. El problema que veo es que nuestra aplicación Discourse tiene alias, por lo que puedo iniciar sesión con 2 URL. Ambas han sido configuradas en Azure con las URL de devolución de llamada adecuadas. Noté que la llamada a https://discourse.company.com/auth/oidc está devolviendo la URL de Ubicación con la URL del alias, como https://login-blah-bla/authorize?client_id=&redirect_uri=https%3A%2F%[2Fdiscourse.us.company.com](http://2fdiscourse.us.company.com/)%2Fauth%2Foidc%2Fcallback.\n¿No debería respetar la URL de origen?\n\nHay un openid_connect_error_redirects pero creo que es en caso de errores. ¿Alguna idea de cómo puedo cambiar la redirección a la autoridad (también conocida como discourse.company.com).

[steinhh (Stein Haugan)]

Durante una instalación manual de paquetes, recibo esto:

e Mensaje post-instalación de oauth2:
e
e Has instalado oauth2 versión 1.4.11, que está en fin de vida útil (EOL).
e No se anticipa más soporte para la serie 1.4.x.

Y recomendaciones para actualizar a la versión 2 de oauth2. Me sentiría mucho más cómodo sin mensajes de este tipo, ¿tienen planes de actualizar?

También recibo:
e Has instalado oauth versión 1.1.0, ¡felicidades!
e
e El soporte no comercial para la serie 1.x terminará en abril de 2025. Por favor, haz un plan para actualizar a la próxima versión antes de esa fecha.
e El único cambio que romperá compatibilidad será la eliminación del soporte para Ruby 2.7 y otras versiones que también habrán alcanzado su fin de vida útil (EOL) para entonces.

Pero supongo que eso no es “tú”?

[SamKer]

Hola,
la opción Allow new registrations (Permitir nuevos registros) es estrictamente necesaria para el funcionamiento del plugin. Esto permite crear automáticamente la cuenta en la primera conexión a Discourse y muestra un botón “register” (registrar). Pero, ¿sería posible permitir la desactivación?: es decir, no dejar la posibilidad al usuario que se conecta a través de OpenID Connect de modificar sus parámetros y crear directamente su cuenta. Esto permitiría eliminar de la visualización los botones “register” (registrar) que no tienen razón de ser en este contexto.

Cordialmente.

[marlowleon]

¿Pudiste resolverlo? Estoy atascado en el mismo mensaje.

[marlowleon]

Oye, ¿pudiste configurar esto? No sé por qué estoy estancado con esto, de los cientos de aplicaciones que he gestionado con OpenID o autenticación, esta es la que más problemas me está dando.