Shinyproxy: Führen Sie Shinyproxy nur auf https (443) aus

@garyallenkt Konnten Sie dieses Problem
Vielen Dank!

Irgendwelche Updates zu diesem Thema?

OpenAnalytics hat bei der Lösung dieses Problems großartige Arbeit geleistet.

Sie sollten in der Lage sein, die neueste Version von ShinyProxy (2.3.0) zu erhalten und der aktualisierten Dokumentation hier zu folgen - https://www.shinyproxy.io/security/#https -ssl-tls

Viel Glück.

Hallo @garyallenkt ,

Vielen Dank für Ihre schnelle Antwort. Ich habe es mit der neuesten Version versucht, aber das Problem besteht in meinem Fall weiterhin. Ich bette den gesamten Shinyproxy in Iframe ein. Um sich anzumelden, leitet der Server die HTTPS-Verbindung auf eine HTTP-Verbindung um, die von den meisten Browsern nicht zugelassen wird. Wisst ihr wie ich das beheben kann?

Grüße

@fmichielssen

Ich verwende einen Fork aus dem Telethon Kids Repo und sie verwenden auch 2.3.0, aber nur um sicher zu gehen, habe ich auch das Image von openanalytics gezogen. Als Referenz sind hier meine Konfigurationen.

docker_compose.yaml

version: "3.6"
services:
  nginx:
    image: nginx:alpine
    container_name: tki_nginx
    restart: on-failure
    networks:
      - tki-net
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
      - ./data/certbot/conf:/etc/letsencrypt
      - ./data/certbot/www:/var/www/certbot
    ports:
      - 80:80
      - 443:443
    command: "/bin/sh -c 'while :; do sleep 6h & wait $${!}; nginx -s reload; done & nginx -g \"daemon off;\"'"
    depends_on:
      - shinyproxy

  certbot:
    image: certbot/certbot
    container_name: certbot
    restart: on-failure
    volumes:
      - ./data/certbot/conf:/etc/letsencrypt
      - ./data/certbot/www:/var/www/certbot
    entrypoint: "/bin/sh -c 'trap exit TERM; while :; do certbot renew; sleep 12h & wait $${!}; done;'"

  influxdb:
    image: influxdb:1.7.3-alpine
    container_name: tki_influxdb
    restart: on-failure
    volumes:
      - ./run_first_time.sh:/home/run_first_time.sh
      - type: volume
        source: shinyproxy_usage
        target: /var/lib/influxdb
        volume:
          nocopy: true
    networks:
      - tki-net
    ports:
      - 8083:8083
      - 8086:8086

  shinyproxy:
    depends_on:
      - influxdb
    image: openanalytics/shinyproxy
    container_name: open_analytics_shinyproxy
    restart: on-failure
    networks:
      - tki-net
    volumes:
      - ./application.yml:/opt/shinyproxy/application.yml
      - /var/run/docker.sock:/var/run/docker.sock
    expose:
      - 8080


networks:
  tki-net:
    name: tki-net

volumes:
  shinyproxy_usage:

application.yaml

proxy:
  title: Lorem ipsum

  hide-navbar: true
  landing-page: /
  heartbeat-rate: 10000
  heartbeat-timeout: 600000
  port: 8080
  docker:
    internal-networking: true
  authentication: openid
  openid:
    auth-url: https://lorem-ipsum.auth0.com/authorize
    token-url: https://lorem-ipsumauth0.com/oauth/token
    jwks-url: https://lorem-ipsum.auth0.com/.well-known/jwks.json
    client-id: SUPERCOOL
    client-secret: SUPERCOOLSECRET

  server:
      useForwardHeaders: true
  specs:
  - id: lorem_ipsum
    display-name: Lorem Ipsum
    description:  
    container-cmd: ["R", "-e", "shiny::runApp('/root/app')"]
    container-image: lorem/ipsum
    container-network: tki-net
    container-env:
      user: "shiny"
      environment:
        - APPLICATION_LOGS_TO_STDOUT=false
  usage-stats-url: http://influxdb:8086/write?db=shinyproxy_usagestats

und nginx.conf

worker_processes 1;
events {
  worker_connections 1024;
}

http {
  sendfile on;
  upstream tki_shinyproxy {
    server open_analytics_shinyproxy:8080;
  }


  server {
    listen 80;
    server_name example.org;
    server_tokens off;
  }

  server {
    listen 443;
    server_name example.org;
    server_tokens off;

    ssl on;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;


    # SSL 
    ssl_certificate /etc/letsencrypt/live/example.org/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.org/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;


    location / {
      proxy_pass http://tki_shinyproxy;

      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
      proxy_read_timeout 600s;

      proxy_redirect off;
      proxy_set_header Host $http_host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
    }
  }
}

Irgendein mögliches Update dazu? @garyallenkt @fmichielssen

Habe es geschafft, es zu beheben.
Dieser Code

 server:
      useForwardHeaders: true

muss draußen sein proxy:

server ist tatsächlich ein Block der obersten Ebene und nicht innerhalb von proxy

Leider habe ich das gleiche Problem mit Shinyproxy 2.3.1

Ich habe diesen Block außerhalb des Proxy-Blocks in der Datei application.yml

Server:
useForwardHeaders: true

und ich habe den Nginx-Proxy genau wie in der Dokumentation beschrieben eingerichtet. Ich auch (um zu testen, ob ich gerade einen dummen ngnix-Fehler gemacht habe, habe einen Apache-Server eingerichtet und genau das gleiche Problem gehabt).

Meine Nginx-Konfigurationsblöcke sind:

server {
  listen                80;
  server_name           mydomain.com;
  rewrite     ^(.*)     https://$server_name$1 permanent;
}

server {
  listen                443 ssl;
  server_name           mydomain.com;
  access_log            /var/log/nginx/shinyproxy.access.log;
  error_log             /var/log/nginx/shinyproxy.error.log error;

  ssl on;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

  ssl_certificate      <path to crt>
  ssl_certificate_key   <path to key> 

   location / {
       proxy_pass          http://127.0.0.1:3600/;

       proxy_http_version 1.1;
       proxy_set_header Upgrade $http_upgrade;
       proxy_set_header Connection "upgrade";
       proxy_read_timeout 600s;

       proxy_redirect    off;
       proxy_set_header  Host             $http_host;
       proxy_set_header  X-Real-IP        $remote_addr;
       proxy_set_header  X-Forwarded-For  $proxy_add_x_forwarded_for;
       proxy_set_header  X-Forwarded-Proto $scheme;
     }

}

Hat jemand eine Idee, woran es liegen könnte? oder sogar Gedanken darüber, wie man es beheben kann?

Was ist der Fehler? Können Sie Ihre Konfigurationsdateien so teilen, wie ich es getan habe? Vielleicht kann ich Dir helfen

@greenspray danke fürs

Abgesehen vom Ändern des Ports und dem Hinzufügen der serverforward-Headerzeile habe ich versucht, alles genau so zu belassen, wie es installiert wurde. Ich habe dies sogar mit Shiny Proxy 2.3.0 getestet, da dies für alle in diesem Thread zu funktionieren schien, aber das hatte das gleiche Problem.

proxy:
  title: My Title
  logo-url: http://www.openanalytics.eu/sites/www.openanalytics.eu/themes/oa/logo.png
  landing-page: /
  heartbeat-rate: 10000
  heartbeat-timeout: 60000
  port: 3600
  authentication: simple
  admin-groups: scientists
  users:
  - name: jack
    password: password1
    groups: scientists
  - name: jeff
    password: password1
    groups: mathematicians
  # Docker configuration
  docker:
    cert-path: /home/none
    url: http://localhost:2375
    port-range-start: 20000
  specs:
  - id: 01_hello
    display-name: Hello Application
    description: Application which demonstrates the basics of a Shiny app
    container-cmd: ["R", "-e", "shinyproxy::run_01_hello()"]
    container-image: openanalytics/shinyproxy-demo
    access-groups: [scientists, mathematicians]

server:
  useForwardHeaders: true

logging:
  file:
    shinyproxy3.log

Ich habe stattdessen auch Apache als Webserver getestet und habe das gleiche Problem. Meine beiden aktuellen Theorien sind, dass entweder etwas mit meiner application.yml-Einrichtung nicht stimmt, oder dass etwas in meinem Proxy-Block die Umleitung auf http zulässt, weil ich den Proxy / Reverse-Proxy nicht verstehe.

@Claire-Kelley was ist dein genauer Fehler?

@greenspray9 Ich

@ckelley-ct Leider habe ich keine Erfahrung mit der gewünschten Anmeldeart. Vielleicht gibt es eine Art Umleitung?

Ich habe das gleiche Problem, hast du eine Lösung gefunden?

@HEPBO3AH ja habe ich - für mich war das Problem mit dem unsicheren Bild (die Zeile logo-url: http://www.openanalytics.eu/sites/www.openanalytics.eu/themes/oa/logo.png in the Beispielcode oben). Wenn Sie dies in ein über https bereitgestelltes Bild ändern oder es entfernen, wird das Problem behoben.

@HEPBO3AH @ckelley-ct FYI, wir haben das Bild nach https://www.openanalytics.eu/shinyproxy/logo.png verschoben

Ich habe es geschafft, den Reverse-Proxy mit nginx zu erstellen und mich mit einfacher Authentifizierung sicher anzumelden, aber sobald ich versuche, openid zu verwenden, schlägt es fehl, weil es http als Rückrufprotokoll verwendet:

https://login.microsoftonline.com/9ac05e7d-e6a1-433a-9801-a60642903c2b/oauth2/authorize?response_type=code&client_id=d1abf394-b312-4717-a1c4-daaeee4f3b28&scope=openid%20email&state=5jD7PR% //52.152.166.27/login/oauth2/code/shinyproxy&nonce=EhOFxVuVRksPOxd0hG-CKPDd2s78bhFIzSSC_PPU5-Q

Fehler AADSTS50011 erhalten: Die in der Anfrage angegebene Antwort-URL stimmt nicht mit den für die Anwendung konfigurierten Antwort-URLs überein: 'd1abf394-b312-4717-a1c4-daaeee4f3b28'.

Dies ist meine application.yml für Shinyproxy 2.4.0, Shiny Proxy 2.3.1 scheint von Microsoft Edge zu funktionieren

proxy:
  title: Open Analytics Shiny Proxy
  logo-url: https://www.openanalytics.eu/shinyproxy/logo.png
  landing-page: /
  heartbeat-rate: 10000
  heartbeat-timeout: 60000
  port: 8080
  authentication: openid
  admin-groups: scientists
  #bind-address: 127.0.0.1
  # Example: 'simple' authentication configuration
  users:
  - name: jack
    password: password
    groups: scientists
  - name: jeff
    password: password
    groups: mathematicians
  # Example: 'openid' authentication configuration
  openid:
    auth-url: https://login.microsoftonline.com/9ac05e7d-e6a1-433a-9801-a60642903c2b/oauth2/authorize
    token-url: https://login.microsoftonline.com/9ac05e7d-e6a1-433a-9801-a60642903c2b/oauth2/token
    jwks-url: https://login.microsoftonline.com/common/discovery/keys
    client-id: d1abf394-b312-4717-a1c4-daaeee4f3b28
    client-secret: xxx
  # Docker configuration
  docker:
    container-backend: docker
    port-range-start: 20000
    container-protocol: https
  specs:
  - id: euler
    display-name: Euler's number
    #container-cmd: ["R", "-e", "shiny::runApp('/root/euler')"]
    container-image: euler
    access-groups: scientists


server:
    useForwardHeaders: true

logging:
  file:
    shinyproxy.log

Ich habe es geschafft, den Reverse-Proxy mit nginx zu erstellen und mich mit einfacher Authentifizierung sicher anzumelden, aber sobald ich versuche, openid zu verwenden, schlägt es fehl, weil es http als Rückrufprotokoll verwendet:

https://login.microsoftonline.com/9ac05e7d-e6a1-433a-9801-a60642903c2b/oauth2/authorize?response_type=code&client_id=d1abf394-b312-4717-a1c4-daaeee4f3b28&scope=openid%20email&state=5jD7PR% //52.152.166.27/login/oauth2/code/shinyproxy&nonce=EhOFxVuVRksPOxd0hG-CKPDd2s78bhFIzSSC_PPU5-Q

Fehler AADSTS50011 erhalten: Die in der Anfrage angegebene Antwort-URL stimmt nicht mit den für die Anwendung konfigurierten Antwort-URLs überein: 'd1abf394-b312-4717-a1c4-daaeee4f3b28'.

gleicher Fehler bei mir mit 2,4

Hallo @danilfm123 , @roberts2727 also mit ShinyProxy 2.4 wird die folgende Konfiguration nicht mehr funktionieren:

server:
    useForwardHeaders: true

stattdessen müssen Sie verwenden:

server:
  forward-headers-strategy: native

Können Sie berichten, ob dies das Problem für Sie löst?

Problem gelöst! Danke mein Herr.

Ja, es funktioniert, tötet aber das Paket DT

ShinyProxy 2.4 die folgende Konf

Wäre es erwähnenswert, dass auf https://www.shinyproxy.io/security/?

Hallo @shosaco das ist bereits zu unserer neuen Website hinzugefügt: https://www.shinyproxy.io/documentation/security/#forward -headers . Die URL, auf die Sie verweisen, ist ein Überbleibsel der alten Website, die ich jetzt aufgeräumt habe.