EDOMI-Releases/Updates | Aktuell: Version 2.03

[eriche]

geht ein VPN "on demand" auch unter Android?

[gaert]

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

Die "Sicherheitsdebatte" hatten wir ja bereits in der Vergangenheit - daher hier nur kurz: EDOMI ist prinzipiell *unsicher* konfiguriert und das ist auch nicht's Schlimmes, da EDOMI typischer Weise im Heimnetz Verwendung findet (dort sind eher selten Hacker und Man-In-The-Middle zu erwarten). Ein Zugriff von extern ist m.E. nur über ein VPN sinnvoll und praktikabel - insb. Portforwarding/etc. sind Schwachsinn und MUSS vermieden werden. Natürlich kann man jetzt noch SSL/etc. druffpacken - und sich mit 1000 Details plagen (Kamera-Streams, Browser-Gedöhns, abgelaufene Zertifikate, Serverabsicherung, uvm.), aber warum sollte man sich das antun?!

@gulk2k
Im Grunde jederzeit möglich... Das nächste Update ist auch schon in Planung - ich wollte nur noch ein paar Dinge von der Liste reinnehmen, daher dauert's noch ein paar Tage.

[coliflower]

gaert Hi Christian,

WSS wird wie schon gesagt nicht unterstützt! Wenn Du die Verbindung via HTTPS aufbaust, müsste der Socket auch per WSS (verschlüsselt) aufgebaut werden - was aber nicht möglich ist (weil nicht implementiert).

auch wenn ich es nicht brauche und falls es möglich / relativ einfach wäre den Code auf WWS zu ändern, wäre das in Summe nicht einfacher ? All die Probleme, Diskussionen und die HTTPS-Fraktion auf einmal zu „erschlagen" ? Nur so ein Gedanke, ich weiß, manchmal dauert es ein bissi bis du etwas für gut empfindest

[bernsen]

Liebe Leute - nutzt doch einfach VPN! Dafür wurde es doch erfunden Diese ganzen Krücken per dynDNS+Forwarding usw. sind in der heutigen Zeit vollkommen obsolet und unsicher...

Dann kann man eine Alexa Steuerung etc. aber auch vergessen.

Da ich momentan nicht zu Hause bin habe ich es noch nicht umgesetzt. Aber mit mod_proxy_wstunnel sollte sich das umsetzen lassen. Dafür muss Edomi auch kein WSS können.

[gulp2k]

gaert

Kannst du schon absehen wann die "Ipad Optimierung" kommt?
Da das bei mir die Hauptclients sind würde ich gerne mit dem Update so lange warten.
Vielleicht kann da ja "kurz" und "Hotfix" kommen so 1.52a

[gaert]

WSS wird wie schon gesagt nicht unterstützt! Wenn Du die Verbindung via HTTPS aufbaust, müsste der Socket auch per WSS (verschlüsselt) aufgebaut werden - was aber nicht möglich ist (weil nicht implementiert).

Daher: Liebe Leute - nutzt doch einfach VPN! Dafür wurde es doch erfunden Diese ganzen Krücken per dynDNS+Forwarding usw. sind in der heutigen Zeit vollkommen obsolet und unsicher...

[Ing-Dom]

Bei mir geht es ebenfalls mit der Änderung aus 2582 nicht.

Chrome meldet bei mir:

Mixed Content: The page at 'https://edomi.proxy.xxxxx.de/visu/' was loaded over HTTPS, but attempted to connect to the insecure WebSocket endpoint 'ws://edomi.proxy.xxxxxxx.de:8080/'. This request has been blocked; this endpoint must be available over WSS.

Lasse ich den Zugriff dann zu, geht auch nich
t.

Leite ich aber Port 8080 stur an edomi weiter (Portforwarding im Router), dann geht es. Ist aber unsicher.

[gaert]

Bald gibt's ein weiteres Status-KO für Visu-Accounts mit dem einprägsamen Namen "Nutzerinteraktion" - dieses KO wird bei jedem Seitenaufruf/Werteingabe/etc. durch den Nutzer auf die Visu-ID gesetzt. Praktisch z.B. für Anwesenheitserkennung/Bildschirmschoner-Geschichten/etc...

[jonofe]

Ich habe erstmal port 8080 direkt weitergeleitet auf den EDOMI und die änderung aus Post #2582 umgesetzt... funktioniert aber nicht....
Hängt das damit zusammen das ich per https://edomi.xxxxx.de auf den EDOMI zugreife (der Apache Reverse Proxy setzt auf HTTP://edomi.intern.lan um)

Aus meiner Sicht liegt da daran, dass EDOMI via JavaScript dem Browser mitteilt wohin die WS Verbindung aufgemacht werden soll. Zunächst war es die global_serverIP und nach der Änderung aus dem Post oben ist es der aufgerufene Hostname (window.location.host). Da der Proxy edomi.intern.lan aufruft, bekommt dein Browser diese Adresse als Websocket Host mitgeteilt und da es ein privater DNS Name ist, geht das schief, denn dein Browser versucht dann zu edomi.intern.lan.de:8080 zu connecten statt zu edomi.xxxxxx.de. Wenn du mal testweise statt window.location.host einfach deinen DynDNS Namen edomi.xxxxxx.de einträgst, dann sollte es vermutlich von extern funktionieren aber vermutlich von intern nicht.

Evtl. kann man den Reverseproxy irgendwie umbiegen, so dass es richtig funktioniert, ich habe aber keine Ahnung was man da tun muss.

EDIT: Je länger ich drüber nachdenke, umso mehr glaube ich, dass die obige Vermutung falsch ist. Könnte auch sein, dass sowohl der Proxy als auch der Browser versuchen eine Websocket Verbindung aufzubauen und der Proxy diese natürlich nicht weiterleitet und ggf. die WS Verbindung des Browsers abgelehnt wird, weil der Reverse Proxy sie ja schon aufgebaut hat.

Ich muss zugeben, es sind nur Vermutungen. Wenn die letzte Vermutung stimmt, dann sollte auch das Ersetzen mit dem DynDNS Namen nicht funktionieren.

[ratzi82]

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ß

[ThorstenGehrig]

Hi
update lief sauber durch.
Die Visu ist nun sauschnell (verglichen zu vorher 1 sekunde). Super.
Ich habe den EDOMI hinter einem Reverse-Proxy mit Authentifizierung per Client-Zertifikat... das ging dann erstmal nicht mehr von außen (intern geht super).
Ich habe erstmal port 8080 direkt weitergeleitet auf den EDOMI und die änderung aus Post #2582 umgesetzt... funktioniert aber nicht....
Hängt das damit zusammen das ich per https://edomi.xxxxx.de auf den EDOMI zugreife (der Apache Reverse Proxy setzt auf HTTP://edomi.intern.lan um) - und der AJAX kein ssl kann? Ich hätte jetzt erhofft das de AJAX erstmal plain durchgeht...

Bin für Tips dankbar.

Gruß
Thorsten

[hapi]

vento66 War nicht so ernst gemeint. Danke für den Service, ganz angenehm im Zug zu lesen, ob man betroffen ist oder nicht!

[vento66]

hapi Ah sorry, aber ich hab die Datenbank nur nach "writeToTraceLog" durchsuchen lassen. Auskommentierte Zeilen sind da natürlich auch dabei...

[hapi]

So dann starte ich mal den elektronischen Pranger, derer die sich laut gaert schämen sollten
...
hapi 19000420
...

Jetzt stand ich fast eine Woche am Pranger wegen zweier bereits auskommentierter //writeToTraceLog... Also bei 19000420 bedarf es keiner Änderung.

Bei der Gelegenheit: Super cool, die neuen Reaktionszeiten der Visu!!! Vielen Dank, Überweisung folgt.

[Ing-Dom]

Gut, dann übernehme ich das mal so - auch wenn Portforwarding wie gesagt keine gute Idee ist.

ist ja nicht nur für Portforwrding, sondern auch für Proxy notwendig. Und das ist richtig konfiguriert genauso sicher wie ein VPN.