<p>shinyproxy genera URL de redireccionamiento incorrecto cuando se usa keycloak</p>

¿Estableciste esto en application.yml?

server:
  useForwardHeaders: true

Desde aquí: https://www.shinyproxy.io/security/#https -ssl-tls

No estoy seguro de cuál es el equivalente de Apache, pero en nginx esto es probablemente lo que soluciona su problema:

    proxy_set_header  Host    $http_host;

@aiham Gracias.

Lo tengo funcionando. Es debido a que falta useForwardHeaders: true

estoy usando useForwardHeaders: true pero todavía tengo el problema

@ danielfm123

estoy usando useForwardHeaders: true pero todavía tengo el problema

Existe otra posibilidad relacionada con los certificados SSL. Si sus certificados instalados en Keycloak no son de confianza pública (la CA raíz e intermedia no están en la lista de confianza predeterminada de Java), debe agregarlos en la CA de confianza predeterminada de JRE. El JRE es el que ejecuta su Shinyproxy.

la ubicación predeterminada es JAVA_HOME ---> JRE -> lib ---> seguridad -> cacerts JAVA_HOME ---> JRE -> lib ---> seguridad -> cacerts

comandos para importar como este.

keytool -import -noprompt -alias -your-root -file /opt/jboss/your-root.crt -keystore / etc / pki / java / cacerts -storepass changeit

Lo hice, no funciona, probé shinyproxy 2.3.1 en lugar de 2.4.1 y envía el redirect_uri correcto, pero solo funciona en algunos navegadores, en el resto obtengo err_too_many_redirects

¿Sus certificados son de confianza pública? Me encontré con esto durante la fase de prueba, los certificados no son de confianza pública. Debe importar la CA raíz y la CA intermedia a la tienda de confianza del navegador. Cada navegador es diferente, depende de su sistema operativo y navegador. En mi caso, estoy usando Windows, después de importar certificados a la zona de confianza y tanto IE como Chrome funcionan bien después de eso.

Aquí está mi sugerencia,

1. Durante la fase de prueba, siempre que tenga un navegador que funcione, será lo suficientemente bueno.
2. para la implementación de producción, agregue un proxy web seguro antes de shinyproxy y keycloak. Configúrelo para usar SSL desde el proxy web y use certificados públicos de confianza. Esta es una estructura de implementación más segura. Si su organización no tiene un proxy web seguro por hardware, puede usar Apache HTTPD como proxy web inverso y también como balanceador de carga.

Está validado con certbot ... Me las arreglé para hacerlo funcionar con shinyproxy 2.3.1 y una cuenta de directorio activo diferente ...

Pero hay un error en shinyproxy 2.4.1 y 2.4.0

Hola @ danielfm123 , verifiqué algunas cosas aquí y no puedo reproducir ningún problema con redirect_uri en ShinyProxy 2.4.0 / 1.
¿Puede abrir un nuevo problema con la siguiente información? De esa forma puedo investigarlo y ver si hay un error.

• cómo estás ejecutando ShinyProxy (usando el jar, Docker, Kubernetes, etc.)
• proporcione su archivo application.yaml (elimine los valores confidenciales) Vea aquí cómo puede publicar el código
  
  
  
  • ¿Está utilizando un equilibrador de carga o un proxy inverso? cuál, cómo está configurado (por ejemplo, está pasando los encabezados X-Forward), etc.
  
  
  • ¿Qué proveedor de openid estás usando? ¿Están configuradas correctamente las URL de devolución de llamada?
  
  
  • ¿shinyproxy registra algún error? Proporcione el seguimiento de la pila completa.
  
  

Tengo el mismo problema.

La configuración con keycloak, proxy inverso apache2 y shinyproxy 2.3.1 funciona bien. Ejecuto shinyproxy a través de Docker. Shinyproxy redirige correctamente a https://testauth.example.com.

Cuando cambio a shinyproxy 2.4.1, redirect_uri contiene la IP interna (http://192.168.51.27:8082) en lugar de la dirección a la que se puede acceder desde el exterior y aparece un error: "Parámetro no válido: redirect_uri".

Esta es la parte relevante de mi application.yml:

proxy:
  title: AUTHTEST
  hide-navbar: false
  template-path: /templates
  favicon-path: /www/favicon.png
  heartbeat-rate: 10000
  heartbeat-timeout: 600000
  port: 8080
  admin-groups: admin
  container-wait-time: 30000
  authentication: keycloak
  keycloak:
    realm: shinyr
    auth-server-url: http://192.168.51.122:8080/auth
    resource: shinyr
    credentials-secret: <secret>
  docker:
    internal-networking: true
  specs:
  - id: test
    display-name: Euler App
    description: Test App
    container-cmd: ["R", "-e", "shiny::runApp('/root/euler')"]
    container-image: saletelligence/test
    container-network: authtest_authtest_net
    access-groups: [admin, pm]
logging:
  file:
    shinyproxy.log
server:
  useForwardHeaders: true

Esta es la configuración de apache:

<VirtualHost *:443>
        RequestHeader set X-Forwarded-Proto "https"
        RequestHeader set X-Forwarded-Port "443"
        ServerName testauth.example.com

        RewriteEngine On
        RewriteCond %{HTTP:Upgrade} =websocket
        RewriteRule /(.*) ws://192.168.51.27:8082/$1 [P,L]
        RewriteCond %{HTTP:Upgrade} !=websocket
        RewriteRule /(.*) http://192.168.51.27:8082/$1 [P,L]
        ProxyRequests Off

        ProxyPass "/" "http://192.168.51.27:8082/"
        ProxyPassReverse "/" "http://192.168.51.27:8082/"

        SSLProxyEngine On
        SSLEngine On
        SSLCertificateFile /etc/apache2/sslcert/example.crt
        SSLCertificateKeyFile /etc/apache2/sslcert/example_pem.key
        SSLCACertificateFile /etc/apache2/sslcert/example_bundle.pem
</VirtualHost>

Hola @ eastclintw00d

Intente utilizar:

server:
  forward-headers-strategy: "native"

En lugar de

server:
  useForwardHeaders: true

¡Gracias!

Hola @LEDfan

Eso resolvió el problema.

¡Gracias por la rápida respuesta!

Eso funciona pero mata el paquete DT

@ danielfm123 ¿Está seguro de que está ejecutando shinyproxy 2.4.1? DT está funcionando bien para mí.

@ danielfm123 @ eastclintw00d Las solicitudes POST (como las hizo, por ejemplo, DT) no funcionan cuando se usa OIDC con ShinyProxy actual (2.4.1). Una solución de @LEDfan será parte de un próximo lanzamiento, pero este no es el tema de este hilo.

El problema con la solicitud POST ahora se solucionó en la versión 2.4.2

Se actualiza la documentación relacionada con el problema original.

Bloquearé este problema para que podamos mantenerlos.
Por supuesto, como siempre, ¡no dude en abrir un nuevo número si encuentra algún problema!