Reverse Proxy

[psilo]

smai ich glaube ich hatte das für jede url eigenständig konfiguriert mit verweis auf die gleiche .htpasswd datei... ist aber lange her. ich kanns ja nochmal testen, wenn ich das thema nginx sowieso dokumentiere.

das clientzertifikat ist mir gefühlt aber sowieso sicherer als die basic auth - daher würde ich das wenn nur zu dokuzwecken mal nachtesten.

[smai]

Ich habe zwar keine praktische Erfahrung damit, aber soweit ich es gelesen habe, müsste basic auth mit Websockets funktionieren.

Da beim Einsatz eines Reverse Proxies der Websocket und die Visu-Webpage aus Sicht des Clients auf demselben Server und Port läuft, müsste das meines Erachtens automatisch funktionieren. Die Authentifizierung geschieht beim Aufruf der ersten Visu-Page, danach sendet der Browser den authorization Header bei jedem HTTP-Request an diese Adresse mit, also auch beim Aufbau der Websocket-Verbindung.

Aber wie geschrieben ist das alles nur Theorie, getestet habe ich es nicht.

psilo Hast du vielleicht bei deinen Versuchen das basic auth nur für "location /smartVISU" aktiviert? Damit es für den Websocket übernommen wird, musst du es (ausschliesslich) auf "location /" aktivieren.
In einem normalen Webserver wird es dann auf /smartVISU vererbt. Evtl. ist das bei nginx anders, weil es ja separate Backend Server sind. Dann wäre es wohl tatsächlich nicht so einfach.

[psilo]

TCr82 funktioniert die Basic Auth bei Dir auch bei Websockets? Von dem was ich gelesen habe, dürfte es bei Websockets nicht gehen, weil das Protokoll ein anderes ist... Ich habe das unter NGINX auch nie hinbekommen (was meine These bestätigt hat). Daher war ich dann auf Clientzertifikate ausgewichen, was für mich auch eine relativ charmante Lösung war.

Falls Basic Auth doch geht: wie gibst du die in der SV an?

user:password@...?

[smai]

Bei Änderungen, geht er immer zurück zum Standardport, egal ob leer oder nicht.
Wenn ich das System ändere (z.B. von SmartHomeNG zu FHEM) will ich mit höchster Wahrscheinlichkeit auch einen anderen Port. Deshalb wird dann gleich der Standardport eingetragen, welcher wohl für den Grossteil der Benutzer stimmt.
Aber zugegeben, wenn man z.B. von SHNG zu Offline und zurück ändert, ist es unsinnig.

Das Problem ist, dass in der Config nur ein Feld für den Port vorgesehen ist und ich nur für diese Kleinigkeit nicht die Zeit investieren wollte, um alles umzubauen.
Für die höchste Usability müsste der Port pro System gespeichert werden, so dass man beim Wechseln immer wieder seinen zum gewählten System zuletzt eingetragenen bekommt.

Aber mal ehrlich: Wie oft wechselt man das System in der Praxis?

EDIT: Nachdem ich deinen Beitrag nochmal gelesen habe, denke ich, dass du die Korrektur von letzter Nacht noch nicht gepulled hast.
Zuvor wurde der Port nämlich fälschlicherweise bei jedem Öffnen der Config-Seite zurückgesetzt (egal ob leer oder nicht).

[TCr82]

Ich hab da mal an die anderen noch eine Frage, die das noch umgesetzt haben. Im Web-Backend von sh.ng sieh man als Client so leider nur localhost. Kann man das durch einen Header ändern? Oder müsste man dazu was an sh.ng anpassen?

Hat hierzu jemand eine Idee?

Wegen dem nicht änderbaren Port habe ich noch was anzumerken. Wenn kein Port drin ist will er immer zurück auf den Standard Port und man muss bei Änderungen jetzt immer aufpassen das man den Port raus löscht, bevor man speichert. Denke der Standard Port sollte nur nebenan als Text vermerkt werden und nicht als Wert in dem Formular.

[TCr82]

okay, danke.

[smai]

So, der Patch von TCr82 ist gemerged und der Bug mit dem nicht änderbaren Port gefixt.

[smai]

Im master gibt's auch keine config.ini, sondern eine config.php Du nutzt also wohl develop.
Den Patch werde ich gerne aufnehmen. Allerdings ist mir nicht ganz klar, wozu die Bedingung mit den Standardports für http und https da ist.

Edit: Ok, habe den Sinn der Bedingung nun begriffen. Aber wirklich notwendig ist sie nicht, es schadet ja nicht, den Port explizit anzugeben, auch wenn es der Standardport ist. Ansonsten müsstest du noch den ':' bedingen beim Websocket unten.

[TCr82]

smai Kannst du dazu auch etwas sagen? Besteht der Bug im atktuellen Master noch?

Also ich habe in der config.ini das drin stehen (bin auf develop, in master wohl wirklich noch nicht drin):

driver_address = ""
driver_port = ""

Das führt dazu, dass der driver den host+port automatisch ermittelt. Naja, das mit dem Port hatte nicht ganz funktioniert wenn man einen alternativen Port benutzt (was man bei einem Zugriff von Extern immer machen sollte), dazu mein patch (vielleicht komme ich irgendwann mal dazu das zu pushen):

diff --git a/driver/io_smarthome.py.js b/driver/io_smarthome.py.js
index ebd60ce..66fc792 100755
--- a/driver/io_smarthome.py.js
+++ b/driver/io_smarthome.py.js
@@ -151,6 +151,12 @@ var io = {
                                // use url of current page if not defined
                                io.address = location.hostname;
                        }
+                       if (!io.port) {
+                               // use port of current page if not defined and needed
+                               if ( ! ((location.protocol == 'https' && location.port == '443') || (location.protocol == 'http' && location.port == '80')) ) {
+                                       io.port = location.port;
+                               }
+                       }
                }
                io.socket = new WebSocket(protocol + io.address + ':' + io.port);

Gruß

[TCr82]

Hi, da ich das ganze mittlerweile mal mit apache2 nachgebaut habe, wollte ich euch damit auch erhellen - sicher kanns der ein oder andere gebrauchen.

        <IfModule mod_rewrite.c>
                RewriteEngine on

                <IfModule mod_proxy.c>

                ProxyPreserveHost On
                ProxyVia On

                # socket.io 1.0+ starts all connections with an HTTP polling request
                RewriteCond %{QUERY_STRING} transport=polling       [NC]
                RewriteRule /(.*)           http://localhost:2424/$1 [P]

                # When socket.io wants to initiate a WebSocket connection, it sends an
                # "upgrade: websocket" request that should be transferred to ws://
                RewriteCond %{HTTP:Upgrade} websocket               [NC]
                RewriteRule /(.*)           ws://localhost:2424/$1  [P]

                </IfModule>
        </IfModule>

        <Location />
                AuthName "Private"
                AuthType Basic
                AuthUserFile /etc/apache2/htpasswd
                Order allow,deny
                Require valid-user
                Allow from 192.168.0.0/16 2a02:XXXX:XXX:XXX::/64 fd00:XXXX:XXXX:XXXX::/64 fe80::/64
                Satisfy any
        </Location>

        <Location /public-folder>
                Satisfy any
        </Location>

Damit wird für den kompletten Webserver bei zugriffen von EXTERN ein Basic Auth geschalten, das MUSS natürlich über eine HTTPS Webseite laufen, damit es auch sicher ist (darauf will ich hier aber jetzt nicht eingehen). Die Interne Ausnahme ist mit dem "Allow from ..." realisiert. Die Ordner die auch ohne Basic-Auth abrufbar sein sollen, einfach wie hier mit dem /public-folder "freischalten".

Ich hab da mal an die anderen noch eine Frage, die das noch umgesetzt haben. Im Web-Backend von sh.ng sieh man als Client so leider nur localhost. Kann man das durch einen Header ändern? Oder müsste man dazu was an sh.ng anpassen?

Zu dem Trennen der Systeme kann ich für mich sagen - unnötig - weil es bringt auch nicht unbedingt mehr Sicherheit und frisst somit nur mehr Strom.

Gruß

[smai]

Der Bug im Config-GUI existiert im develop noch. Im master hat er hingegen, wie psilo schreibt, nie existiert.

[psilo]

im master gibt es nicht mal die neue konfigurations gui

[Max2612]

dann gab es da noch einen bug mit der konfiguration und dem smarthome_io treiber. ich weiss nicht, ob smai das inzwischen behoben hat? ich musste den 443er auch noch direkt in den driver reinschreiben

smai Kannst du dazu auch etwas sagen? Besteht der Bug im atktuellen Master noch?

Gruß,Max

[smai]

starte den apache doch mit port 80 (ist er wahrsch. sowieso) und lass nginx auf 443. und aender die weiterleitung auf http. dann sollte es jetzt schon gehen

Falls jemand meine Meinung hören will: Genau so würde ich es auch machen, wenn alles auf einem Gerät sein soll.

Auch bei getrennten Systemen kannst du innerhalb des LAN auf HTTPS verzichten, falls du keine internen Angriffe befürchten musst.

In beiden Fällen dann nach aussen im Router bzw. der Firewall natürlich nur Port 443 des nginx durchlassen.

[psilo]

ja, wenn du kein lokales serverzertifikat auf raspi2 machst. die letsencrypt gehen nur auf dem raspi1. da das aber im lan ist reicht http auch...