<p>shinyproxy génère une mauvaise URL de redirection lors de l'utilisation de keycloak</p>

L'avez-vous défini dans application.yml ?

server:
  useForwardHeaders: true

À partir d'ici : https://www.shinyproxy.io/security/#https -ssl-tls

Je ne sais pas ce qu'est l'équivalent Apache, mais dans nginx, c'est probablement ce qui résout votre problème :

    proxy_set_header  Host    $http_host;

@aiham Merci.

Je l'ai fait fonctionner. C'est à cause de l'absence de useForwardHeaders : true

j'utilise useForwardHeaders: vrai mais toujours le problème

@danielfm123

j'utilise useForwardHeaders: vrai mais toujours le problème

Il existe une autre possibilité liée aux certificats SSL. Si vos certificats installés sur Keycloak ne sont pas de confiance publique (l'autorité de certification racine et intermédiaire ne figure pas dans la liste de confiance par défaut de Java), vous devez les ajouter à l'autorité de certification de confiance par défaut JRE. Le JRE est celui qui exécute votre Shinyproxy.

l'emplacement par défaut est JAVA_HOME---> JRE -->lib---> security--> cacerts JAVA_HOME---> JRE -->lib---> security--> cacerts

commandes à importer comme ceci.

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

Je l'ai fait, cela ne fonctionne pas, j'ai essayé shinyproxy 2.3.1 au lieu de 2.4.1 et il envoie le bon redirect_uri, mais ne fonctionne que dans certains navigateurs, dans le reste j'obtiens err_too_many_redirects

Vos certificats sont-ils de confiance publique ? J'ai rencontré cela pendant la phase de test, les certificats ne sont pas approuvés par le public. Vous devez importer l'autorité de certification racine et l'autorité de certification intermédiaire dans le magasin de confiance du navigateur. Chaque navigateur est différent, dépend de votre système d'exploitation et de votre navigateur. Dans mon cas, j'utilise Windows, après avoir importé des certificats dans la zone de confiance et IE et Chrome fonctionnent correctement après cela.

Voici ma proposition,

1. pendant la phase de test, tant que vous avez un navigateur qui fonctionne, ce sera assez bon.
2. pour le déploiement en production, ajoutez un proxy Web sécurisé avant shinyproxy et keycloak. Configurez-le pour utiliser le SSL du proxy Web et utiliser des certificats de confiance publics. Il s'agit d'une structure de déploiement mieux sécurisée. Si votre organisation ne dispose pas d'un proxy Web sécurisé, vous pouvez utiliser Apache HTTPD comme proxy Web inverse et équilibreur de charge.

Il est validé avec certbot.... J'ai réussi à le faire fonctionner avec shinyproxy 2.3.1 et un autre compte Active Directory...

Mais il y a un bug sur shinyproxy 2.4.1 et 2.4.0

Salut @danielfm123 , j'ai vérifié quelques choses ici, et je ne peux reproduire aucun problème avec redirect_uri dans ShinyProxy 2.4.0/1.
Pouvez-vous ouvrir un nouveau numéro avec les informations suivantes ? De cette façon, je peux l'examiner et voir s'il y a un bug.

• comment exécutez-vous ShinyProxy (en utilisant le pot, Docker, Kubernetes, etc.)
• fournissez votre fichier application.yaml (supprimez les valeurs sensibles) Voyez ici comment publier du code
  
  
  
  • utilisez-vous un équilibreur de charge ou un proxy inverse ? lequel, comment est-il configuré (par exemple, passe-t-il les en-têtes X-Forwarded), etc.
  
  
  • quel fournisseur openid utilisez-vous? Les URL de rappel sont-elles correctement configurées ?
  
  
  • shinyproxy enregistre-t-il une erreur ? Veuillez donner la trace complète de la pile.
  
  

J'ai le même problème.

La configuration avec keycloak, apache2 reverse proxy et shinyproxy 2.3.1 fonctionne très bien. Je lance shinyproxy via Docker. Shinyproxy redirige correctement vers https://testauth.example.com.

Lorsque je passe à shinyproxy 2.4.1, le redirect_uri contient l'IP interne (http://192.168.51.27:8082) au lieu de l'adresse accessible de l'extérieur et j'obtiens une erreur : "Paramètre invalide : redirect_uri".

Voici la partie pertinente de mon 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

Voici la configuration d'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>

Salut @eastclintw00d

Veuillez essayer d'utiliser :

server:
  forward-headers-strategy: "native"

À la place de

server:
  useForwardHeaders: true

Merci!

Salut @LEDfan

Cela a résolu le problème.

Merci pour votre réponse rapide!

Ça marche mais ça tue le paquet DT

@danielfm123 Êtes-vous sûr d'utiliser shinyproxy 2.4.1 ? DT fonctionne bien pour moi.

@danielfm123 @eastclintw00d Les requêtes POST (comme faites par exemple par DT) ne fonctionnent pas lors de l'utilisation d'OIDC avec le ShinyProxy actuel (2.4.1). Un correctif de @LEDfan fera partie d'une prochaine version, mais ce n'est pas le sujet de ce fil.

Le problème avec la requête POST est désormais résolu dans la version 2.4.2

La documentation relative au numéro d'origine est mise à jour.

Je vais verrouiller ce problème, afin que les problèmes restent maintenables pour nous.
Bien sûr, comme toujours n'hésitez pas à ouvrir un nouveau numéro si vous rencontrez un problème !