IoBroker (und vis) über ReverseProxy

dodi666

Also ich denke es ist alles richtig installiert, und der Reiter ist auch da.

Im internen Netz kann ich meine Skripte ja auch bearbeiten.

Beim Aufruf von extern kommt dann aber nur ne leere Seite mit "Loading".
2863_2017-07-21_081131.jpg

nobody

Hi nobody,

das wäre super nett.

Ich spreche aber nicht von einer zusätzlichen Installation, sondern von dem Standardreiter "Skript" der iobroker.admin Installation.

…nur damit wir vom Gleichen sprechen...

Vielen Dank schonmal

Gruß Sascha `

Hallo Sascha,

ich hab mir das mal etwas genauer angesehen.

Dass der Skript-Reiter beim Laden hängen bleibt, liegt an js-Dateien. Diese hab ich nun explizit für die Admin-Seite aufgenommen.

Leider klappt der Skript-Reiter so immer noch nicht.

Das Problem ist, das der Javascript-Adapter eine eigene Websocket-Verbindung über socket.io aufmacht. Hierfür verwendet er die URL /socket.io/. Diese ist leider identisch zum Verbindungsaufbau bei VIS. Da beim websocket-Aufbau auch im HTTP-Header keine Attribute drin sind, um zwischen Admin und VIS unterscheiden zu können, funktioniert leider nur entweder der Zugriff auf VIS oder auf Skripte.

Der Admin-Adapter selbst baut seine Websocket-Verbindung mittlerweile mit einem relativen Pfad auf, sodass dieser als /iobroker/socket.io/ beim Apache-Server ankommt und somit unterschieden werden kann.

Meine Bitte an Bluefox wäre es, den Pfad für socket.io entweder auch beim Javascript-Adapter relativ zu setzen oder in der URL ein zusätzliches Attribut aufzunehmen, wodurch die Ziele unterschieden werden können. Dann kann ich das Template entsprechend erweitern.

Viele Grüße

Markus

p.s.:

Ich hab das Template im Post 17 entsprechend erweitert.

http://forum.iobroker.net/viewtopic.php … 971#p31971

dodi666

Hi Markus,

vielen Dank.

Aber genau verstehen tue ich nicht, was ich jetzt machen muss…

Bin noch nicht so richtig in der Materie drin

Gruß

Sascha

nobody

~~@dodi666:~~

Hi Markus,

vielen Dank.

Aber genau verstehen tue ich nicht, was ich jetzt machen muss…

Bin noch nicht so richtig in der Materie drin

Gruß

Sascha `

Hallo Sascha,

zurzeit kannst du leider garnichts machen. Damit sowohl der Zugriff auf den Reiter Javascript als auch auf die VIS-Seite über denselben Reverse-Proxy-Server möglich ist, müssen alle eintreffenden Anfragen eindeutig dem richtigen Ziel zugeordnet werden können.

Dies ist eben bei der Websocket-Verbindung für die Hintergrundkommunikation des Javascript-Adapters zurzeit nicht möglich, weil die URL hier vollständig identisch mit der für VIS ist. Deswegen gehen die Requests zurzeit an den Webserver-Port für VIS, der sie aber nicht beantworten kann. Ohne eine Änderung an der Anwendung komme ich hier nicht weiter.

dodi666

Ok, das habe ich jetzt verstanden.

Besteht denn die Hoffnung das Bluefox das ändern wird.

Du schreibst, du hast das Template angepasst….was hast du denn dann angepasst?

Grüße

Sascha

nobody

~~@dodi666:~~

Ok, das habe ich jetzt verstanden.

Besteht denn die Hoffnung das Bluefox das ändern wird.

Du schreibst, du hast das Template angepasst….was hast du denn dann angepasst?

Grüße

Sascha `

Auch für den Zugriff auf die Admin-Seite wird jetzt die Websocket-Verbindung durchgeleitet. Dies war möglich, weil hier die URL relativ ist.

Die JS-Dateien für den Javascript-Adapter und einige Konfigurationsseiten der Adapter werden nun explizit weitergeleitet. Somit sollte auch der Reiter Skripte vollständig laden. Es werden jedoch keine Skripte angezeigt.

dodi666

Hallo,

ich würde gerne mit dem IPhone von extern auf ein erstelltes vis zugreifen.

Dazu würde ich gerne die App "Vis Viewer" nutzen.

Kann mir einer sagen, was ich machen muss, um den Zugriff über den Apache hinzubekommen?

In der App kann man einen Link für extern eingeben.

In der Apache Konfig Datei gibt es ja die Möglichkeit im oberen Bereich Einstellungen für eine App zu machen.

Ist es das was ich suche? Wie sieht dann der Aufruf der URL aus, da ich ja irgendwie Nutzer und Password mit übergeben muss?

(Via VPN klappt der Zugang, ist nur etwas umständlich…)

Grüße

Sascha

dodi666

~~@nobody:~~

~~@dodi666:~~

Ok, das habe ich jetzt verstanden.

Besteht denn die Hoffnung das Bluefox das ändern wird.

Du schreibst, du hast das Template angepasst….was hast du denn dann angepasst?

Grüße

Sascha `

Auch für den Zugriff auf die Admin-Seite wird jetzt die Websocket-Verbindung durchgeleitet. Dies war möglich, weil hier die URL relativ ist.

Die JS-Dateien für den Javascript-Adapter und einige Konfigurationsseiten der Adapter werden nun explizit weitergeleitet. Somit sollte auch der Reiter Skripte vollständig laden. Es werden jedoch keine Skripte angezeigt. `

Hi nobody,

hast du eine Ahnung, ob das Problem gefixed wurde?

Grüße

Sascha

nobody

Hallo Sascha,

bis jetzt ist mir nichts bekannt.

Leider

Gruß

Markus

dodi666

Hi Markus,

das ist schade…hast du ne Ahnung, ob was in der Pipeline ist?

Grüße Sascha

nobody

Hallo Sascha,

ich hab mit Bluefox gesprochen und wir haben doch eine Lösung für die Unterscheidung gefunden:

Die Socket-IO-Aufrufe für VIS haben den Parameter key, die für Javascript jedoch nicht. Deswegen habe ich das Skript entsprechend angepasst:

Hier der aktuelle Stand des Skripts:

# Dieses Template enthält Rewrite-Regeln für die Verwendung von Apache 2.4.x als Reverse Proxy mit SSL-Unterstützung für die folgenden Komponenten:
# - ioBroker VIS/Flot/Rickshaw
# - ioBroker Admin
# - ioBroker node-red
# - ioBroker socket-io im Web-Adapter
# - Zugriff auf CCU1/2
# - ioBroker Javascript-Adapter
#
# folgende Module müssen in Apache mindestens installiert und aktiviert sein:
# - ssl
# - proxy
# - rewrite
# - proxy_wstunnel
# - mpm_prefork
# - mod_auth_basic
# - mod_authn_file  -- oder andere Authentifizierungsquelle
# 
# Alle Einträge in eckigen Klammern [] sind durch die eigenen Daten zu ersetzen.
#
# Die Berechtigungsprüfung erfolgt durch Apache mittels HTTP-Basic Authentication oder Parameter an der URL.  Dies hat den Vorteil, das unberechtigte Anfragen erst garnicht zu den Systemen gelangen.
# Da die Verbindung mit SSL/TLS gesichert ist, ist basic-Authentication vollständig ausreichend und am schnellsten. 
# In den lokalen Systemen ist die Authentifizierung auszuschalten, da die Authentifizierungsdaten nicht durchgereicht werden.
# Die Skripte gehen davon aus, dass die lokalen Systeme mittels http angesprochen werden. Falls nicht, müssen die Zeilen entsprechend angepasst werden.

# Folgender Teil ist nur erforderlich, wenn man einen lokalen Bereich auf dem Webserver haben möchte, der unter der gleichen URL erreichbar ist (z.B. um statische Daten abzulegen) und bei dem ein Caching durch den Webserver erfolgen soll.
 <ifmodule mod_cache.c="">LoadModule cache_disk_module modules/mod_cache_disk.so
    <ifmodule mod_cache_disk.c="">CacheRoot "/var/www"
        CacheEnable disk  "/"
        CacheDirLevels 5
        CacheDirLength 3</ifmodule> 

    # When acting as a proxy, don't cache the list
    CacheDisable "/ccu/"
    CacheDisable "/vis/"
    CacheDisable "/iobroker/"
    CacheDisable "/node-red/"</ifmodule> 

# Oberste Modul-Deklaration für den kompletten durch ssl gesicherten Service
 <ifmodule mod_ssl.c=""># Festlegung des Ports, über den der Server erreichbar sein soll.
   <virtualhost _default_:443="">ServerAdmin [ Email des Administrators (Optional)]
      ServerName [ Externe URL des Servers ohne Protokoll, z.B.  haus.meineurl.de] 

      # Stammverzeichnis des Webservers für lokale Inhalte
      DocumentRoot /var/www

        # Festlegung der Eigenschaften für das Root-Directory auf dem Webserver und alle Unterverzeichnisse
      <directory>Options FollowSymLinks
         AllowOverride None

            # Festlegung der Authentifizierungseigenschaften 
         # Hier wird basic-Authentification mit Liste der berechtigten User konfiguriert.
         # Anleitung zur Konfiguration von Benutzern siehe https://httpd.apache.org/docs/current/howto/auth.html
         AuthType basic
         AuthName "home"
         AuthBasicProvider file
         AuthUserFile /etc/apache2/ssl/httpsusers

         # Festlegung, dass die Authentifizierung erfordlich ist. Speziell für die App kann kein Basic-Authentication verwendet werden, da diese Teile im Protokoll nicht enthalten sind.
         # Für die App kann alternativ auf die dort angegeben Daten für User und Password geprüft werden. Diese Werte werden in der URL als Parameter übertragen.
         # Die Werte werden nicht aus der Passwort-Datei ausgelesen sondern müssen hier statisch konfiguriert werden. 
         # Wichtig: Nur der erste Request muss beim Öffnen der Verbindung authentifizieren. 
         # Alle nachfolgenden Request über die gleiche http-Verbindung verwenden automatisch die gleichen Credentials. Deswegen ist beim Zugriff auf VIS die http-Authentifizierung für index.html ausreichend.
         <requireany># Zugriff über URL-Authentifizierung
            <requireall># Erlaubt auch noch die Einschänkung auf andere Eigenschaften
               Require expr %{QUERY_STRING} =~ /user=[ Benutzername in der APP ]&pass=[ Passwort in der APP ]/</requireall> 
                # Für alle anderen Zugriffe ist http-Authentifizierung erforderlich  
            Require valid-user</requireany></directory> 

        # Eintrag falls noch lokale Scripte wie z.B. PHP unterstützt werden sollen (muss natürlich getrennt installiert und eingerichtet werden)
      ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
      <directory "/usr/lib/cgi-bin"="">AllowOverride None
         Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
         Order allow,deny
         Allow from all</directory> 

      # Einrichtung der Zertifikate für die Verschlüsselung
      # Weitere Informationen siehe z.B. https://thomas-leister.de/apache2-webserver-ssl-verschluesselte-verbindungen-ermoeglichen/
      SSLCertificateFile /etc/apache2/ssl/[ Name der Zertifikatdatei ].crt
      SSLCertificateKeyFile /etc/apache2/ssl/[ Name der Datei mit dem privaten Schnlüssel ].key
      SSLCertificateChainFile /etc/apache2/ssl/[ evtl Name der Datei mit der Key Chain bis zum Root-Zertifikat ].crt

      # Rewrite-Regeln
      # Wichtig: Bei den nachfolgenden Mod-Proxy-Einträgen ist die Reihenfolge relevant. Die Auswertung erfolgt von oben nach unten. Das erste passende ProxyPass-Statement gilt.

        # Weiterleitung für Node-Red
      # Wichtig: Damit die Websocket-Verbindung korrekt weitergeleitet werden kann, muss in den Adapter-Einstellungen von Node-Red in "http root directory" "node-red" eingetragen werden.
      # Ohne Websocket-Verbindung kann man trotzdem auf die IDE zugreifen, bekommt jedoch keine Debug-Information angezeigt.
      # Der Zugriff auf Node-erfolgt dann intern http://[ interne IP ]:1880/node-red und extern über https://[ externe URL ]/node-red
      <ifmodule mod_proxy.c="">RewriteEngine On 
         redirectmatch ^/node-red$ /node-red/

         # Spezieller Eintrag für websocket-Verbindung
         RewriteCond %{REQUEST_URI} ^/node-red/comms [NC] 
         RewriteRule /(.*) ws://[ interne IP ]:1880/$1 [P,L] 

         ProxyPass /node-red/ http://[ interne IP ]:1880/node-red/ 
         ProxyPassReverse /node-red/ http://[ interne IP ]:1880/node-red/</ifmodule> 

      # Prototyp für Foscam Webcam
      # Der Zugriff auf die Webcam dann extern über https://[ externe URL ]/video1

      <ifmodule mod_proxy.c="">ProxyRequests off
         RewriteEngine On
         redirectmatch ^/video1$ /video1/
         rewritecond %{REQUEST_URI} ^/video1/
         rewriterule (.*) $1 [PT]

         # Referer Auswertung, falls eine lokale absolute Referenz auf den Seiten ist. In diesem Fall wird /video1 ergänzt, damit ProxyPass matched.
         rewritecond %{HTTP_REFERER} https://[ externe URL ]/video1/ 
         rewriterule ^/(.*) /video1/$1 [PT]

         ProxyPass /video1/ http://[ interne IP ]/
         ProxyPassReverse /video1/ http://[ interne IP ]/</ifmodule> 

      # Rewrite-Regeln für Homematic CCU 
      # Stammt ursprünglich aus Homematic Forum
      # Der Zugriff auf die CCU efolgt intern weiterhin über http://[ interne IP ] und extern über https://[ externe URL ]/ccu

      <ifmodule mod_proxy.c="">ProxyRequests off
         RewriteEngine On
         redirectmatch ^/ccu$ /ccu/
         rewritecond %{REQUEST_URI} ^/ccu/
         rewriterule (.*) $1 [PT]

         # Referer Auswertung, falls eine lokale absolute Referenz auf den Seiten ist. In diesem Fall wird /ccu ergänzt, damit ProxyPass matched.
         rewritecond %{HTTP_REFERER} https://[ externe URL ]/ccu/ [OR]
         rewritecond %{HTTP_REFERER} https://[ externe URL ]/webui/ [OR]
         rewritecond %{HTTP_REFERER} https://[ externe URL ]/pda/ [OR]
         rewritecond %{HTTP_REFERER} https://[ externe URL ]/api/ [OR]
         rewritecond %{HTTP_REFERER} https://[ externe URL ]/addons/xmlapi/ [OR]
         rewritecond %{HTTP_REFERER} https://[ externe URL ]/addons/cuxd/
         rewritecond %{HTTP_REFERER} \?sid\=\@.+\@ [OR]
         rewritecond %{THE_REQUEST} \?sid\=\@.+\@
         rewriterule ^/(.*) /ccu/$1 [PT]
         rewriterule ^/pda/(.*) /ccu/pda/$1
         rewriterule ^/webui/(.*) /ccu/webui/$1
         rewriterule ^/addons/db/(.*) /ccu/addons/db/$1
         rewriterule ^/addons/xmlapi/(.*) /ccu/addons/xmlapi/$1
         rewriterule ^/addons/cuxd/(.*) /ccu/addons/cuxd/$1
         ProxyPass /ccu/ http://[ interne IP ]/ timeout=1200
         ProxyPassReverse /ccu/ http://[ interne IP ]/ timeout=1200</ifmodule> 

      # Rewrite-Regeln für ioBroker Admin
      # Der Zugriff auf die Admin-Seite efolgt intern weiterhin über http://[ interne IP ]:8081 und extern über https://[ externe URL ]/iobroker

                # Websocket Admin
               <ifmodule mod_proxy.c="">RewriteEngine On 
                     Redirectmatch ^/iobroker/socket.io$ /iobroker/socket.io/
                     RewriteCond %{REQUEST_URI} ^/iobroker/socket.io/ 
                     RewriteCond %{QUERY_STRING} transport=websocket
                     RewriteRule ^/(.*) /iobrokerwss/$1 [PT]
                     ProxyPass /iobrokerwss/iobroker/socket.io/ ws://localhost:8081/socket.io/ timeout=1200 Keepalive=On</ifmodule> 

      <ifmodule mod_proxy.c="">ProxyRequests off
         RewriteEngine On
         redirectmatch ^/iobroker$ /iobroker/
         rewritecond %{REQUEST_URI} ^/iobroker/
         rewriterule (.*) $1 [PT]
         rewritecond %{HTTP_REFERER} https://[ externe URL ]/iobroker/ [OR]
                        rewritecond %{REQUEST_URI} ^/css/adapter.css [OR]
                        rewritecond %{REQUEST_URI} ^/js/translate.js [OR]
                        rewritecond %{REQUEST_URI} ^/js/adapter/ [OR]
                        rewritecond %{REQUEST_URI} ^/adapter/ [OR]
                        rewritecond %{REQUEST_URI} ^/js/adapter-settings.js [OR]
                        rewritecond %{REQUEST_URI} ^/lib/js/jqGrid/ [OR]
                        rewritecond %{REQUEST_URI} ^/lib/css/jquery.multiselect-1.13.css [OR]
                        rewritecond %{REQUEST_URI} ^/lib/js/jquery-ui.min.js [OR]
                        rewritecond %{REQUEST_URI} ^/lib/js/loStorage.js [OR]
                        rewritecond %{REQUEST_URI} ^/lib/js/ace-1.2.0/ace.js [OR]
                        rewritecond %{REQUEST_URI} ^/js/selectID.js  [OR]
                        rewritecond %{REQUEST_URI} ^/lib/js/loStorage.js  [OR]
                        rewritecond %{REQUEST_URI} ^/lib/js/ace-1.2.0/ace.js [OR]
                        rewritecond %{REQUEST_URI} ^/js/selectID.js [OR]
                        rewritecond %{REQUEST_URI} ^/lib/js/ace-1.2.0/mode-javascript.js [OR]
                        rewritecond %{REQUEST_URI} ^/lib/js/ace-1.2.0/worker-javascript.js      
         rewriterule ^/(.*) /iobroker/$1 [PT]

         ProxyPass /iobroker/ http://[ interne IP ]:8081/ timeout=1200
         ProxyPassReverse /iobroker/ http://[ interne IP ]:8081/ timeout=1200</ifmodule> 

      # Rewrite-Regeln für ioBroker VIS
      # Die socket.io-Kommunikation und der Zugriff auf /lib wird nachfolgend getrennt geregelt (geht bestimmt auch einfacher hier lokal)
      # Wichtig: Im web-Adapter mit "Socket.IO Instance" auf integriert stehen.
      # Der Zugriff auf die Admin-Seite efolgt intern weiterhin über http://[ interne IP ]:8082/vis/index.html und extern über https://[ externe URL ]/vis/vis/index.html. 
      <ifmodule mod_proxy.c="">ProxyRequests off
         RewriteEngine On
         redirectmatch ^/vis$ /vis/
         rewritecond %{REQUEST_URI} ^/vis/
         rewriterule (.*) $1 [PT]

         # Referer Auswertung, falls eine lokale absolute Referenz auf den Seiten ist. In diesem Fall wird /vis ergänzt, damit ProxyPass matched.
         # Referenzen auf node-red, static und socket.io werden explizit ausgeschlossen.
         rewritecond %{HTTP_REFERER} https://[ externe URL ]/vis/
         rewritecond %{REQUEST_URI} !^/node-red/
         rewritecond %{REQUEST_URI} !^/static/
         rewritecond %{REQUEST_URI} !^/socket.io/
         rewriterule ^/(.*) /vis/$1 [PT]

         ProxyPass /vis/ http://[ interne IP ]:8082/ timeout=10
         ProxyPassReverse /vis/ http://[ interne IP ]:8082/ timeout=10</ifmodule> 

      # Rewrite-Regeln für einen direkten Zugriff auf das Verzeichnis /lib des Web-Servers von ioBroker VIS ohne Referer
      # Dürfte normalerweise nicht benötigt werden.
      <ifmodule mod_proxy.c="">ProxyRequests off
         RewriteEngine On
         redirectmatch ^/lib$ /lib/
         rewritecond %{REQUEST_URI} ^/lib/
         rewriterule (.*) $1 [PT]
         ProxyPass /lib/ http://[ interne IP ]:8082/lib/ timeout=10
         ProxyPassReverse /lib/ http://[ interne IP ]:8082/lib/ timeout=10</ifmodule> 

      # Rewrite-Regeln für einen direkten Zugriff auf auf flot ohne VIS
      <ifmodule mod_proxy.c="">ProxyRequests off
         RewriteEngine On
         redirectmatch ^/flot$ /flot/
         rewritecond %{REQUEST_URI} ^/flot/
         rewriterule (.*) $1 [PT]
         ProxyPass /flot/ http://[ interne IP ]/flot/ timeout=10
         ProxyPassReverse /flot/ http://[ interne IP ]:8082/flot/ timeout=10</ifmodule> 

      # Rewrite-Regeln für einen direkten Zugriff auf auf rickshaw ohne VIS
      <ifmodule mod_proxy.c="">ProxyRequests off
         RewriteEngine On
         redirectmatch ^/rickshaw$ /rickshaw/
         rewritecond %{REQUEST_URI} ^/rickshaw/
         rewriterule (.*) $1 [PT]
         ProxyPass /rickshaw/ http://[ interne IP ]:8082/rickshaw/ timeout=10
         ProxyPassReverse /rickshaw/ http://[ interne IP ]/rickshaw/ timeout=10</ifmodule> 

      # Rewrite-Regeln für die socket.io Websocket-Verbindung von VIS und APP sowie Javascript-Adapter
      # Wichtig: Da socket.io im Webadapter auf intern steht, sollte hier auch auf den Web-Adapter und nicht auf einen separaten socket.io-Adapter referenziert werden.
      # Setzt externes WSS (Verschlüsselte Websocket-Verbindung) auf internen WS (ohne SSL/TLS) um.

                # Websocket Javascript
      <ifmodule mod_proxy.c="">RewriteEngine On 
         Redirectmatch ^/socket.io$ /socket.io/
         RewriteCond %{REQUEST_URI} ^/socket.io/ 
         RewriteCond %{QUERY_STRING} transport=websocket
         RewriteCond %{QUERY_STRING} !key=
         RewriteRule ^/(.*) /wss2/$1 [PT]
         ProxyPass /wss2/socket.io/ ws://[ interne IP ]:8081/socket.io/ timeout=1200 Keepalive=On</ifmodule> 

      # Websocket VIS
      <ifmodule mod_proxy.c="">RewriteEngine On 
         Redirectmatch ^/socket.io$ /socket.io/
         RewriteCond %{REQUEST_URI} ^/socket.io/ 
         RewriteCond %{QUERY_STRING} transport=websocket
         RewriteCond %{QUERY_STRING} key=
         RewriteRule ^/(.*) /wss/$1 [PT]
         ProxyPass /wss/socket.io/ ws://[ interne IP ]:8082/socket.io/ timeout=1200 Keepalive=On</ifmodule> 

      # Rewrite-Regeln für die Datei _socket im Hauptverzeichnis vom Web-Server
      <ifmodule mod_proxy.c="">ProxyRequests off
         RewriteEngine On
         Redirectmatch ^/_socket$ /_socket/
         RewriteCond %{REQUEST_URI} ^/_socket/

         RewriteRule (.*) $1 [PT]
         ProxyPass /_socket/ http://[ interne IP ]:8082/_socket/
         ProxyPassReverse /_socket http://[ interne IP ]:8082/_socket/</ifmodule> 

      # Rewrite-Regeln für die socket.io Verbindung im Polling-Modus über HTTPS von VIS und APP sowie Javascript-Adapter
      # Wichtig: Da socket.io im Webadapter auf intern steht, sollte hier auch auf den Web-Adapter und nicht auf einen separaten socket.io-Adapter referenziert werden.

      # socket.io Javascript
      <ifmodule mod_proxy.c="">ProxyRequests off
         RewriteEngine On
         Redirectmatch ^/socket.io$ /socket.io/
         RewriteCond %{REQUEST_URI} ^/socket.io/
         RewriteCond %{QUERY_STRING} transport=polling
         RewriteCond %{QUERY_STRING} !key=
         RewriteRule (.*) /adminsocket/$1 [PT]
         ProxyPass /adminsocket/socket.io/ http://[ interne IP ]:8081/socket.io/
         ProxyPassReverse /adminsocket/socket.io/ http://[ interne IP ]:8081/socket.io/</ifmodule> 

      # socket.io VIS
      <ifmodule mod_proxy.c="">ProxyRequests off
         RewriteEngine On
         Redirectmatch ^/socket.io$ /socket.io/
         RewriteCond %{REQUEST_URI} ^/socket.io/
         RewriteCond %{QUERY_STRING} transport=polling
         RewriteCond %{QUERY_STRING} key=
         RewriteRule (.*) $1 [PT]
         ProxyPass /socket.io/ http://[ interne IP ]:8082/socket.io/
         ProxyPassReverse /socket.io/ http://[ interne IP ]:8082/socket.io/</ifmodule> 

      # Parameter für die Steuerung der Log-Ausgabe beim Rewrite
      # Die Logausgabe kann durch Entfernen der # aktiviert werden
      #LogLevel warn 
      #LogLevel alert rewrite:trace8
      #CustomLog ${APACHE_LOG_DIR}/ssl_access2.log combined 

      # Generelles Anschalten von SSL
      SSLEngine on 

      # Sonderregeln für Scripte
      <filesmatch "\.(shtml|phtml|php)$"="">
         SSLOptions +StdEnvVars 
      </filesmatch> 
      <directory usr/lib/cgi-bin=""> 
         SSLOptions +StdEnvVars 
      </directory></virtualhost></ifmodule>

Kannst du prüfen, ob dies so auch bei dir funktioniert?

Viele Grüße

Markus

dodi666

Das ist ja Hammer,

werde es die Tage ausprobieren, und mich dann melden.

Vielen Dank

Sascha

nobody

Nur als kleine Vorwarnung:

die Android-App klappt so leider noch nicht, da hier die URL anders gebildet wird. Hierfür braucht es noch ein Update.

Als Workarround kann man für VIS zusätzlich auch user= zusätzlich zu ref= zur Unterscheidung verwenden.

RewriteCond %{QUERY_STRING} key= [OR]
RewriteCond %{QUERY_STRING} user=

uweklatt

Hallo,

welchen Vorteil hat ein Reverse Proxy für private ioBroker Installationen?

Warum nicht per VPN von Aussen auf die lokale Installation zugreifen?

Das bietet doch einen sauberen und sicheren Zugang auf als privaten Dienste ohne Einschränkungen.

Tschau

Uwe

lobomau

~~@uweklatt:~~

Hallo,

welchen Vorteil hat ein Reverse Proxy für private ioBroker Installationen?

Warum nicht per VPN von Aussen auf die lokale Installation zugreifen?

Das bietet doch einen sauberen und sicheren Zugang auf als privatwn Dienste ohne Einschränkungen.

Tschau

Uwe `
Der Vorteil ist dass ich nicht umständlich VPN am Handy starten muss oder an manchen Rechnern kein VPN installieren kann/darf. Oder gibt es da einen anderen Weg?

Aber von der Sicherheit ist VPN natürlich sehr gut, benutze ich auch.

robsdobs

Man kann auch aus Umgebungen heraus zugreifen, bei denen VPN Verbindungen schlicht gesperrt sind.

Gesendet von meinem A0001 mit Tapatalk

dodi666

~~@nobody:~~

Hallo Sascha,

ich hab mit Bluefox gesprochen und wir haben doch eine Lösung für die Unterscheidung gefunden:

Die Socket-IO-Aufrufe für VIS haben den Parameter key, die für Javascript jedoch nicht. Deswegen habe ich das Skript entsprechend angepasst:

Hier der aktuelle Stand des Skripts:
# Dieses Template enthält Rewrite-Regeln für die Verwendung von Apache 2.4.x als Reverse Proxy mit SSL-Unterstützung für die folgenden Komponenten:
# - ioBroker VIS/Flot/Rickshaw
# - ioBroker Admin
# - ioBroker node-red
# - ioBroker socket-io im Web-Adapter
# - Zugriff auf CCU1/2
# - ioBroker Javascript-Adapter
.
.
.
.
       
   
Kannst du prüfen, ob dies so auch bei dir funktioniert?

Viele Grüße

Markus `

Hi Markus,

habe es gerade kurz angetestet und es scheint zu funktionieren.

Werde die nächsten Tage noch was intensiver testen und dann berichten.

Ganz lieben Dank

Gruß

Sascha

patrick131184

Hallo zusammen,

ich benutze aktuell folgende konfig:

http://forum.iobroker.net/viewtopic.php … 227#p31971

Leider habe ich das Problem, das ich beim Zugriff meine Anzeige immer wieder neu lädt (fast jede Minute).

Wenn ich die Webseitenanzeige intern aufrufe ist alles gut.

Kann es sein, dass ich hier in einen Timeout laufe?

Hat jemand das Problem auch schonmal gehabt?

Viele Grüße Patrick
4015_2017-11-03_10_50_54-vis.png

dodi666

Hi,

seid dem letzten ioBroker Update habe ich auch wieder Probleme.

ioBroker.admin Objekte, wird nicht geladen
ioBroker.admin Aufzählungen, wird nicht geladen
ioBroker.admin Skripte, wird nicht geladen

gibt es einen Fix dazu?

Grüße

Sascha

nobody

~~@dodi666:~~

Hi,

seid dem letzten ioBroker Update habe ich auch wieder Probleme.

ioBroker.admin Objekte, wird nicht geladen

ioBroker.admin Aufzählungen, wird nicht geladen

ioBroker.admin Skripte, wird nicht geladen

gibt es einen Fix dazu? `
Hi,

tritt das Problem immer noch auf?

Ich hab heute alle Updates eingespielt und den Browser-Cache gelöscht. Bisher funktioniert bei mir der Zugriff über den Reverse Proxy.

Gruß

Markus

NEWS

IoBroker (und vis) über ReverseProxy

IoBroker (und vis) über ReverseProxy

Support us

60

32.4k

81.3k

1.3m