IoBroker (und vis) über ReverseProxy

robsdobs

Danke und Sorry, das ich mich erst jetzt melde, musste IO Broker komplett neu aufsetzen, weil es nichtmehr lief. Ich werde das morgen nochmal probieren.

nobody

Hallo robsdobs,

ich hab am Wochenende meine Konfiguration komplett überarbeitet, weil die socket-io-Verbindung immer von Websocket auf den Poll-Modus zurückgefallen war und bei der socket.io-Verbindung in der App die http-Authentifizierung nicht funktioniert (weil kein http-Request vorher die Verbindung freischaltet), ich aber unbedingt eine Authentifizierung haben wollte.

Generell geht der Websocket-Support erst ab Apache 2.4 und erfordert neben den Modulen ssl, mod_proxy und mod_rewrite noch das Modul proxy_wstunnel.

Ich versuche mal in den nächsten Tagen das ganze allgemeingültig zu beschreiben.

Gruß

Markus

nobody

Hallo,

wie versprochen hier ein Template einer Site-Konfiguration für Apache 2.4 als Reverse-Proxy-Server für ioBroker und CCU.

Die Beschreibung befindet sich inline als Kommentare. Die aufgeführten Module müssen in Apache aktiviert sein. Insbesondere wstunnel ist für die Websocket-Kommunikation erforderlich.

Alle URL- und IP-Daten in eckigen Klammern müssen durch die eigenen Daten ersetzt werden.

Gruß

Markus

! ````

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

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

Eine gute Anleitung, wie man auf dem Raspi den Apache installiert befindet sich z.B. hier: http://www.lxccu.com/manuals:apache-rev … oxy-manual

robsdobs

Danke, sowohl die alte als auch die neue Variante funktionieren.

unter https://[DNS Name]/vis zeigt er zwar die linkliste an, diese links funktionieren nicht. Hier muss man nur wissen, das diese nur mit 2 mal vis funktionieren.

Das war das Problem, mit https://[DNS Name]/vis/vis/ geht es.

Die Seite http://www.lxccu.com/manuals:apache-rev … oxy-manual ist mir bekannt und auf die CCU kann ich auch problemlos zugreifen. Hier geht von außen auch der Zugriff über https://[IP Adresse]/ccu, das funktioniert bei ioBroker leider nicht, hier geht nur der DNS Name (wird benötigt, wenn der DynDNS Anbieter geblockt ist).

Kann man da noch etwas ändern, das der Zugriff zu ioBroker auch über die IP Adresse geht?

Danke & Gruß

Robert

nobody

Die Angabe des dns-Namens beim referer ist eine Art "Seiteneinwahlschutz". Du kannst das Pattern aber auch so ändern, das jede URL matched, wenn danach /vis oder /iobroker steht.

Wichtig sind die Einträge für socket.io.

Es läuft auch ohne, aber dann wird statt websocket der polling-Modus verwendet und die Daten über separate http Requests jede Sekunde von Client abgerufen statt vom Server aktiv gesendet . Und dann geht im Client der Netzverkehr, CPU und Speicherbedarf hoch.

Gesendet von meinem SM-G900F mit Tapatalk

nobody

Ich hab oben noch Regeln ergänzt, sodass nun auch die meisten Adaptereinstellungen auf der Admin-Seite korrekt angezeigt werden.

nobody

Hallo Homoran,

könntest du die Skripte für die Reverse-Proxy-Konfiguration in die Dokumentation aufnehmen?

Den Wunsch von extern gesichert auf die Komponenten zugreifen zu können dürften einige haben.

mfg

Markus

Homoran

~~@nobody:~~

Hallo Homoran,

könntest du die Skripte für die Reverse-Proxy-Konfiguration in die Dokumentation aufnehmen? `
Ja, könnte ich

Aber sag bitte einem js-Legastheniker (und bash + …), welche genau. ggf per PN und mit einem zweizeiler für die Skriptbeschreibung.

Gruß

Rainer

MrLee

Moin!

Hat jemand das schonmal für nginx umgesetzt?

bis denne

Mr.Lee

dodi666

Hallo zusammen,

bin ganz neu im iobroker Forum und derzeit eigentlich nur stiller Mitleser.

Habe den Reverse Proxy soweit installiert, leider funktioniert bei mir der Zugriff auf den Reiter Skripte nicht.

Die Seite wird aufgerufen und dann steht oben links in der Ecke "Loading…." und nichts weiter passiert.

Ich habe nur den Eintrag default-ssl.conf übernommen, der für den iobroker.admin notwendig ist.

Alles andere funktioniert auch, nur leider die Skripte nicht.

Kann mir einer von euch vielleicht weiterhelfen?

Vielen Dank

Sascha

nobody

Ich hab den Javascript-Adapter bei mir nicht installiert. Deswegen ist in der Konfiguration hierfür bisher nichts vorgesehen.

Wahrscheinlich ist eine zusätzliche Regel für den Pfad erforderlich.

Ich kann mir das aber leider erst am Wochenende genauer ansehen.

dodi666

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

Dolomiti

Hallo dodi,

du mußt oben links neben "Admin" auf den Stift klicken und dann erscheint ein Menüpunkt "Zeige". Dort Skripte auswählen und der Reiter sollte da sein.

Gruß

Dolomiti

apollon77

Aber auch nur wenn der JavaScript Adapter installiert ist!!

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

~~@dodi666:~~

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.

NEWS

IoBroker (und vis) über ReverseProxy

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

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.

Support us

607
Online

31.7k
Users

79.9k
Topics

1.3m
Posts

NEWS

IoBroker (und vis) über ReverseProxy

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

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.

Support us

607Online

31.7kUsers

79.9kTopics

1.3mPosts

607
Online

31.7k
Users

79.9k
Topics

1.3m
Posts