EDOMI-Releases/Updates | Aktuell: Version 2.03

[starwarsfan]

Bezüglich iPad1: Sorry, aber ich möchte mich damit nicht beschäftigen - EDOMI soll nicht Windows werden, d.h. ich möchte verhindern, dass EDOMI aufgebläht wird mit "uralten" Protokollen und Abwärtskompatibilitäten.

+1, so sehe ich das auch.

[123paultje]

Bezüglich iPad1: Sorry, aber ich möchte mich damit nicht beschäftigen - EDOMI soll nicht Windows werden, d.h. ich möchte verhindern, dass EDOMI aufgebläht wird mit "uralten" Protokollen und Abwärtskompatibilitäten. Denn am Ende führt dies insgesamt nur zu Einbußen für die restlichen 99% der Nutzer - und die Wartung des Codes wird (noch) komplexer. Das iPad 1 (bzw. das entsprechende iOS) ist im Kontext des Computerzeitalters aus der Steinzeit. Wenn ich nun die Besonderheiten uralter Browser etc. auch noch berücksichtige, geht das auf Kosten neuer Features - denn mein Tag hat ja auch nur 24 Stunden

Dann mal ein neue iPad kaufen

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

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

[vento66]

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

[hapi]

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

[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

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

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

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

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

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

[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

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

[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