EDOMI-Releases/Updates | Aktuell: Version 2.03

[gaert]

Rischtisch... Das Thema hatten wir vor einiger Zeit auch bereits

[panzaeron]

LBS-INI-Dateien sind m.E. überflüssig, denn ein Rechtsklick auf einen LBS (Konfiguration) öffnet den LBS-Editor - und dort könnte man ggf. doch diverse Parameter im Quelltext verfügbar machen...

Das stimmt, aber das gilt dann für alle Instanzen des LBS. Aber ich hab mich falsch ausgedrückt und meinte eigentlich eine Vereinfachung für die LBS die jetzt viele Optionen über die Eingänge realisiert haben (Beschattung, Multiroom usw.) wo die Optionen nur für die jeweilige Instanz benötigt werden.

Aber das ist vermutlich doch nicht so einfach, weil man dann eine angenommene LBSxxx.ini für jede Instanz duplizieren (IDxxx.ini) müsste und dabei bereits vorhandene nicht überschreiben darf...

[gaert]

Die edomi.ini wird ausgelesen und daraus ein "Formular" erstellt. Es bleibt also alles beim Alten - die edomi.ini kann also wie gehabt auch per Texteditor modifiziert werden. Das ist auch gut so, denn ggf. ist nach einer Installation die Adminseite noch gar nicht erreichbar.

LBS-INI-Dateien sind m.E. überflüssig, denn ein Rechtsklick auf einen LBS (Konfiguration) öffnet den LBS-Editor - und dort könnte man ggf. doch diverse Parameter im Quelltext verfügbar machen...

[panzaeron]

Top! Wird das "dynamisch" von der .ini generiert? Denn das wäre auch eine tolle Sache wenn man als LBS-Entwickler auf zugehörige LBSxxx.ini Dateien zurück greifen könnte. Denn das würde bei komplexen LBS vieles vereinfachen und teilweise eine Menge Eingänge sparen...

[Brick]

schick...

[gaert]

Da ist was im Busch... Noch nicht fertig, aber die Richtung stimmt:

Bildschirmfoto 2017-09-03 um 08.53.00.png

[gaert]

Bitte macht doch einen neuen Thread dafür auf... Wird ein bisschen OT hier

[Ing-Dom]

So ähnlich müsste es vermutlich in
/usr/local/edomi/www/visu/include/js/main.js rein um Zeile 634 rein, oder?

var protocol = 'ws://';
if (window.location.protocol === 'https:') {
protocol = 'wss://';
}socket=new WebSocket(protocol+serverIp+':'+serverPort);

Damit wird der websocket bei http-verbindung mit ws:// geöffnet und bei https:// mit wss://

Ich denke, dass es reichen önnte, wenn man im proxy ein URL-Rewrite vornimmt - so wie man es bei einer Weiterleitung von https auf http macht.
Der client will ws://xxxxx
Server (proxy) antwortet mit 301 moved permanently => wss://xxxxx
client holt sich wss://xxxxxx

so zumindest bei "normalem" http. Ob das bei websocket so geht, kann ich nicht sicher sagen, glaube aber schon!

[ThorstenGehrig]

Hi
bin ein bisschen am recherchieren. Der proxy_wstunnel scheint nicht zu reichen... weil der client ja ws:// abfragt.
Aber hier bin ich fündig geworden:
https://stackoverflow.com/questions/...s-to-ws-apache

So ähnlich müsste es vermutlich in
/usr/local/edomi/www/visu/include/js/main.js rein um Zeile 634 rein, oder?

var protocol = 'ws://'; 
if (window.location.protocol === 'https:') {
            protocol = 'wss://';
   }socket=new WebSocket(protocol+serverIp+':'+serverPort);

Damit wird der websocket bei http-verbindung mit ws:// geöffnet und bei https:// mit wss://

Jetzt müsste man noch mit dem proxy_wstunnel das redirect auf den edomi machen bei gleichzeitiger umsetzung auf ws://

Gruß
Thorsten

[coliflower]

starwarsfan Hi Yves, das wurde schon hier vorgeschlagen ...

ThorstenGehrig

Ich nutze Edomi zwar selber nicht, aber evtl. könnte das hier https://httpd.apache.org/docs/2.4/mo..._wstunnel.html weiterhelfen.

Gruß

[starwarsfan]

Hallo miteinander,

vermutlich lässt sich da was mit mod_proxy_wstunnel machen, oder?

[Ing-Dom]

Clientseitig ist WSS kein Problem - aber Serverseitig Da EDOMI keine fertigen Libs nutzt, bedeutet das sehr viel Arbeit für mich... Und die setze ich lieber sinnvoll ein, statt Portforwarding etc. zu unterstützen

Hi
@Gaert: es ist OK wenn EDOMI kein https/ssl unterstützt - und simples portforwarding sehe ich auch als unsicher.
Allerdings ist das ganze was einige (u.a. ich) hier machen nicht völlig unsicher und unsinn.

Ich denke der richtige weg müsste - wie von Ratzi vorgeschalten - den reverse proxy auch für den websocket WS/WSS zu konfiguieren... jetzt hab ich nur relavtiv wenig ahnung von dem Websocket-Kram... aber irgendwie kriegen wir das hin.

Gruß Thorsten

Für eine Zugriffsmöglichkeit ohne VPN gibt es Use-Cases. z.B. hinter einem kastrierten Internetzugang (besser: Webzugang) mit HTTP-Proxy.

Serverseitig müsste edomi wohl kein SSL bei den WSS können, das könnte ja der proxy übernehmen.
Nur müsste der edomi-client dann wss:// aufrufen statt ws:// - es sei denn man kann das mit mod_rewrite genauso umbiegen wie bei http/https...

Vielleicht kommt ich am Sonntag dazu etwas rumzuprobieren. Wetter erlaubt eh keine Arbeiten im Garten.

[trollmar]

Hi
@Gaert: es ist OK wenn EDOMI kein https/ssl unterstützt - und simples portforwarding sehe ich auch als unsicher.
Allerdings ist das ganze was einige (u.a. ich) hier machen nicht völlig unsicher und unsinn.
Anstatt einem simplen portforwarding setze ich hier einen Apache-Reverse proxy mit zertifikatsbasierender authentifizierung ein.
Apache prüft ob der client zugelassen ist - und setzt dann das HTTPS auf HTTP um.
So ist das ganze VIEL kompfortabler als ein VPN (es funktioniert "unsichtbar" auf authorisierten clients).
VPNs muss man ein/ausschalten - oder bei "vpn on demand" spezifisch auf die App einschränken oder einen Split-Tunnel machen (um nicht den ganzen regulären Internet-Traffic durch das VPN zu leiten).
So gesehen finde ich ein VPN eher antequiert B-)

Ich denke der richtige weg müsste - wie von Ratzi vorgeschalten - den reverse proxy auch für den websocket WS/WSS zu konfiguieren... jetzt hab ich nur relavtiv wenig ahnung von dem Websocket-Kram... aber irgendwie kriegen wir das hin.

Gruß Thorsten

Schon interessant wie unterschiedlich doch wir alle an sowas gehen.
Interessant ist das alles.

Ich möchte z. B in fremden WLANs meinen gesamten traffic durch den vpn leiten.
Aber vielleicht bin ich auch nur paranoid

[ThorstenGehrig]

Hi
@Gaert: es ist OK wenn EDOMI kein https/ssl unterstützt - und simples portforwarding sehe ich auch als unsicher.
Allerdings ist das ganze was einige (u.a. ich) hier machen nicht völlig unsicher und unsinn.
Anstatt einem simplen portforwarding setze ich hier einen Apache-Reverse proxy mit zertifikatsbasierender authentifizierung ein.
Apache prüft ob der client zugelassen ist - und setzt dann das HTTPS auf HTTP um.
So ist das ganze VIEL kompfortabler als ein VPN (es funktioniert "unsichtbar" auf authorisierten clients).
VPNs muss man ein/ausschalten - oder bei "vpn on demand" spezifisch auf die App einschränken oder einen Split-Tunnel machen (um nicht den ganzen regulären Internet-Traffic durch das VPN zu leiten).
So gesehen finde ich ein VPN eher antequiert B-)

Ich denke der richtige weg müsste - wie von Ratzi vorgeschalten - den reverse proxy auch für den websocket WS/WSS zu konfiguieren... jetzt hab ich nur relavtiv wenig ahnung von dem Websocket-Kram... aber irgendwie kriegen wir das hin.

Gruß Thorsten

[trollmar]

geht ein VPN "on demand" auch unter Android?

Ich würde vorschlagen zu diesem Thema.
VPN ios und Android einen eigenen thread zu öffnen.

Nur soviel. Ich mache das mit "Tasker"