Reverse Proxy

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

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

[smai]

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

[TCr82]

okay, danke.

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

[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).

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

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]

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.

[psilo]

Wen es interessiert: ich baue über die nächsten Tage unter https://github.com/smarthomeNG/smart...s-ReverseProxy mal Doku auf, wie man einen hardwaretechnisch autonomen ReverseProxy mit NGINX aufbaut..

Erweiterungen und Anmerkungen gerne an mich.

[TCr82]

TCr82 funktioniert die Basic Auth bei Dir auch bei Websockets? [...]
Falls Basic Auth doch geht: wie gibst du die in der SV an?

user:password@...?

Hi, also das Basic Auth geht auch mit Websockets, wobei der Browser für Websocket-Zugriffe keinen Auth-Dialog bringt und somit immer nur ein Error 401 zurückgibt beim Zugriff auf den Server. Aber wenn man vorher Angemeldet wurde funktioniert der Zugriff auch automatisch, da der Server die entsprechenden Header mitsendet.

Und wieso muss ich die in der SV angeben? Du meist für die Anmeldung für die Websockets? Wenn ja, geht das Automatisch, sobald man von dem Zugriff auf die Webseite der Visu angemeldet wurde.

Gruß

[psilo]

TCr82 ok ich war der meinung, ich müsste das bei der konfiguration der websocketverbindung mit angeben.. aber du hast recht, wenn der browser checkt, dass er die über den normalen abruf der seiten gesetzte basic auth verwendet, muss man das nicht... ich teste das die tage mal mit nginx durch.

[TCr82]

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

Stimmt so wars. Das war wohl das Problem.

[psilo]

Anbei meine auf "Raspbian Stretch" aktualisierte Anleitung. Aktuell nur mit Basic Auth (geht bei Websockets wirklich):
https://github.com/smarthomeNG/smart...s-ReverseProxy

Speziell das Zeug mit Certbot ging mit Stretch etwas anders. Checkt man das GIT von Letsencrypt aus, gibt es derzeit einen Bug beim Zertifikategenerieren.

Die Anleitung für Clientzertifikate schreibe ich am Wochenende

[TCr82]

     ## Deny certain Referers ##     if ( $http_referer ~* (babes|forsale|girl|jewelry|love|nudit|organic|poker|porn|sex|teen) )     {         return 403;     }

meinst du wirklich dass macht noch alles sinn (von dem hier mal ganz abgesehen, was für mich noch weniger sinn macht), wenn die komplette Seite sowieso per Basic Auth und SSL gesichert ist?

Naja, die Ländersperre kann ich noch dann verstehen, wenn man kein Ultra-Sicheres Passwort für das Auth gewählt hat...

Genauso machst du dann noch zu dem Auth auf / ein Auth auf /smartVISU usw, obwohl das doch von / vererbt wurde?! Ist halt irgendwie alles doppel und dreifach gemoppelt