<p>Shinyproxy generiert falsche Weiterleitungs-URI bei Verwendung von keycloak</p>

Hast du das in application.yml eingestellt?

server:
  useForwardHeaders: true

Von hier: https://www.shinyproxy.io/security/#https -ssl-tls

Ich bin mir nicht sicher, was das Apache-Äquivalent ist, aber in nginx behebt dies wahrscheinlich Ihr Problem:

    proxy_set_header  Host    $http_host;

@aiham Danke.

Ich habe es funktioniert. Es liegt an fehlenden useForwardHeaders: true

Ich benutze useForwardHeaders: true, habe aber immer noch das Problem

@danielfm123

Ich benutze useForwardHeaders: true, habe aber immer noch das Problem

Es gibt eine weitere Möglichkeit im Zusammenhang mit SSL-Zertifikaten. Wenn Ihre auf Keycloak installierten Zertifikate nicht öffentlich vertrauenswürdig sind (die Stamm- und Zwischenzertifizierungsstelle befinden sich nicht in der Standard-Vertrauensliste von Java), müssen Sie sie der vertrauenswürdigen JRE-Standardzertifizierungsstelle hinzufügen. Die JRE ist diejenige, die Ihren Shinyproxy betreibt.

der Standardspeicherort ist JAVA_HOME ---> JRE --> lib ---> Sicherheit --> cacerts JAVA_HOME ---> JRE --> lib ---> Sicherheit --> cacerts

Befehle zum Importieren wie folgt.

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

Ich habe es getan, es funktioniert nicht, ich habe Shinyproxy 2.3.1 anstelle von 2.4.1 ausprobiert und es sendet die richtige redirect_uri, funktioniert aber nur in einigen Browsern, im Rest bekomme ich err_too_many_redirects

Sind Ihre Zertifikate öffentlich vertrauenswürdig? Ich bin während der Testphase darauf gestoßen, dass die Zertifikate nicht öffentlich vertrauenswürdig sind. Sie müssen die Stammzertifizierungsstelle und die Zwischenzertifizierungsstelle in den vertrauenswürdigen Browserspeicher importieren. Jeder Browser ist anders, hängt von Ihrem Betriebssystem und Browser ab. In meinem Fall verwende ich Windows, nachdem ich Certs in die vertrauenswürdige Zone importiert habe und sowohl IE als auch Chrome danach einwandfrei funktionieren.

Hier ist mein Vorschlag,

1. Während der Testphase reicht ein Browser aus, solange er funktioniert.
2. Fügen Sie für die Produktionsbereitstellung einen sicheren Web-Proxy vor Shinyproxy und Keycloak hinzu. Konfigurieren Sie es so, dass SSL vom Webproxy verwendet wird und öffentliche vertrauenswürdige Zertifikate verwendet werden. Dies ist eine bessere sichere Bereitstellungsstruktur. Wenn Ihr Unternehmen keinen hardwaresicheren Webproxy hat, können Sie Apache HTTPD auch als Reverse-Webproxy und Load Balancer verwenden.

Es ist mit certbot validiert.... Ich habe es geschafft, es mit Shinyproxy 2.3.1 und einem anderen Active Directory-Konto zum Laufen zu bringen...

Aber es gibt einen Fehler bei Shinyproxy 2.4.1 und 2.4.0

Hallo @danilfm123 , ich habe hier ein paar Dinge überprüft, und ich kann keine Probleme mit redirect_uri in ShinyProxy 2.4.0/1 reproduzieren.
Können Sie mit den folgenden Informationen eine neue Ausgabe eröffnen? Auf diese Weise kann ich nachschauen und sehen, ob es einen Fehler gibt.

• Wie läuft ShinyProxy (mit JAR, Docker, Kubernetes usw.)
• Stellen Sie Ihre application.yaml-Datei bereit (entfernen Sie sensible Werte) Sehen Sie hier, wie Sie Code posten können
  
  
  
  • Verwenden Sie einen Load-Balancer oder einen Reverse-Proxy? welches, wie ist es konfiguriert (zB übergibt es die X-Forwarded-Header) etc
  
  
  • Welchen Openid-Anbieter verwendest du? Sind die Rückruf-URLs richtig konfiguriert?
  
  
  • protokolliert Shinyproxy Fehler? Bitte geben Sie den vollständigen Stack-Trace an.
  
  

Ich habe das gleiche Problem.

Die Einrichtung mit keycloak, Apache2 Reverse Proxy und Shinyproxy 2.3.1 funktioniert einwandfrei. Ich betreibe Shinyproxy über Docker. Shinyproxy leitet korrekt an https://testauth.example.com weiter.

Wenn ich auf Shinyproxy 2.4.1 wechsle, enthält der redirect_uri die interne IP (http://192.168.51.27:8082) anstelle der von außen erreichbaren Adresse und ich erhalte eine Fehlermeldung: "Ungültiger Parameter: redirect_uri".

Dies ist der relevante Teil meiner 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

Dies ist die Apache-Konfiguration:

<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>

Hallo @eastclintw00d

Bitte versuchen Sie Folgendes zu verwenden:

server:
  forward-headers-strategy: "native"

Anstatt

server:
  useForwardHeaders: true

Vielen Dank!

Hallo @LEDfan

Das hat das Problem gelöst.

Danke, für die schnelle Antwort!

Das funktioniert, aber es tötet das Paket DT

@danielfm123 Sind Sie sicher, dass Sie Shinyproxy 2.4.1 ausführen? DT funktioniert bei mir einwandfrei.

@danilfm123 @eastclintw00d POST-Anfragen (wie zB von DT) funktionieren nicht, wenn OIDC mit aktuellem ShinyProxy (2.4.1) verwendet wird. Ein Fix von @LEDfan wird Teil einer kommenden Veröffentlichung sein, aber das ist nicht das Thema dieses Threads.

Das Problem mit der POST-Anfrage ist jetzt in der Version 2.4.2 behoben

Die Dokumentation zur ursprünglichen Ausgabe wird aktualisiert.

Ich werde diese Ausgabe sperren, damit die Ausgaben für uns wartbar bleiben.
Zögern Sie natürlich nicht, bei Problemen eine neue Ausgabe zu eröffnen!