Fehler in AirStudio 9

[grizzly]

Um also in der Cloud wieder Bilder zu sehen, müssen die Kameras per DynDNS Dienst (s. airStudio > Light-Manager Setup > Weiteres) eingebunden werden. Außerdem ist eine Portfreigabe im Router erforderlich. Dann funktioniert der Zugriff von überall und das Cloud Interface ist komplett HTTPS gesichert.

Danke für den Hinweis. Mit der Einstellung myip und dem Port der Kamera, funktioniert das ganze auch in der Cloud.

Die zweite Kamera, ein Raspberry mit Kamera, funktioniert leider nur über den Aufruf der lokalen IP. Aus der Cloud ist die Kamera nicht erreichbar. Die Einstellungen sind mit der funktionierenden Kamera identisch. Auch der Testaufruf aus dem Config-Tool funktioniert.

Könnte mir hier jemand ein Tipp geben. Evt hat dies schon jemand realisiert.

Gruss aus der Schweiz.

Habe auch das Problem, dass ich 2 ABUS IP Cams nun mit der Dyn-DNS des LM Air konfiguriert habe, die beiden Ports sind auch im Router freigeschaltet aber nach wie vor nur Bild im lokalen Webinterface nicht über die Cloud...

Vor dem Update auf 9.3 lief meine Konfiguration auch über die Dyn-DNS der FritzBox über die Cloud...
Es wäre prima wenn wir hier eine genaue Info bekommen was geändert werden muss, damit das Ganze auch in der Cloud wieder funktioniert.

Besten Dank

[jbmedia]

Vor dem Update auf 9.3 lief meine Konfiguration auch über die Dyn-DNS der FritzBox über die Cloud...
Es wäre prima wenn wir hier eine genaue Info bekommen was geändert werden muss, damit das Ganze auch in der Cloud wieder funktioniert.

In dem Fall sollte es auch weiterhin funktionieren. Einzige Änderung ist, dass das Bild nicht direkt angezeigt, sondern zunächst von einem Server von HTTP nach HTTPS gewandelt wird. Damit dies funktioniert, muss ein Zugriff von "außen" möglich sein. Zum Testen kann man die Snapshot URL im Handy Browser eingeben, WLAN abschalten und schauen, ob die Bilder über Mobilfunk geladen werden. (Der Platzhalter myip muss durch die öffentliche IP oder die DNS URL ersetzt werden.)

Sollte dies funktionieren, aber es wird trotzdem nichts in der Cloud angezeigt, bitte die MAC-Adresse des Light-Managers per PN senden. Damit können wir die Konfiguration auf dem Server kontrollieren.

[grizzly]

Vor dem Update auf 9.3 lief meine Konfiguration auch über die Dyn-DNS der FritzBox über die Cloud...
Es wäre prima wenn wir hier eine genaue Info bekommen was geändert werden muss, damit das Ganze auch in der Cloud wieder funktioniert.

In dem Fall sollte es auch weiterhin funktionieren. Einzige Änderung ist, dass das Bild nicht direkt angezeigt, sondern zunächst von einem Server von HTTP nach HTTPS gewandelt wird. Damit dies funktioniert, muss ein Zugriff von "außen" möglich sein. Zum Testen kann man die Snapshot URL im Handy Browser eingeben, WLAN abschalten und schauen, ob die Bilder über Mobilfunk geladen werden. (Der Platzhalter myip muss durch die öffentliche IP oder die DNS URL ersetzt werden.)

Sollte dies funktionieren, aber es wird trotzdem nichts in der Cloud angezeigt, bitte die MAC-Adresse des Light-Managers per PN senden. Damit können wir die Konfiguration auf dem Server kontrollieren.

Danke für die schnelle Rückmeldung, das Bild wird von "außen" angezeigt. Allerdings nicht über die Weboberfläche und die Cloud.
die MAC Adresse sende ich per PN gleich hinterher.

[jbmedia]

Das Problem liegt im myfritz-Service. Dieser blockiert offenbar bestimmte Server-Anfragen. Stattdessen bitte den DNS Service des Light-Managers nutzen, damit sollte es ohne Probleme funktionieren.

[grizzly]

Das Problem liegt im myfritz-Service. Dieser blockiert offenbar bestimmte Server-Anfragen. Stattdessen bitte den DNS Service des Light-Managers nutzen, damit sollte es ohne Probleme funktionieren.

auch mit dem DNS Service des Light Manager funktioniert es nur lokal nicht in der Cloud..
Habe die Konfig übertragen - MAC Adresse hatte ich per PN mitgeteilt, könnte das bitte noch mal geprüft werden?

[jbmedia]

Die Ursache liegt an der Authentifizierung. Diese erfolgt aktuell per sog. Basic HTTP Authentifizierung, also per vorangestelltem username:password@... . Diese Art der Authentifizierung wird von der Kamera nicht unterstützt. Gibt man den Link im Browser ein, erscheint stattdessen ein Fenster, in dem Anmeldeinformationen händisch eingegeben werden müssen. Bei Abfrage von einem Server geht das natürlich nicht. Es hat nur deshalb in der Vergangenheit funktioniert, weil die eingegebenen Daten vom Browser eine Zeit lang gespeichert werden, z.B. bis zum nächsten Neustart.

Man müsste also die Art der Authentifizierung ändern bzw. wissen, wie die Userdaten per Parameter übergeben werden können. Bei Foscam Kameras hängt man diese z.B. am Ende der URL per usr= und pwd= an. Wenn man Pech hat, weil der Hersteller nichts dergleichen implementiert hat, muss man die Authentifizierung ganz abschalten, um es lauffähig zu machen.

[Digital08]

Man müsste also die Art der Authentifizierung ändern bzw. wissen, wie die Userdaten per Parameter übergeben werden können. Bei Foscam Kameras hängt man diese z.B. am Ende der URL per usr= und pwd= an. Wenn man Pech hat, weil der Hersteller nichts dergleichen implementiert hat, muss man die Authentifizierung ganz abschalten, um es lauffähig zu machen.

Bei mir wider das Problem auch bei der Authentifizierung liegen. Leider weiss ich nicht wie ich es beim Raspberry mit dem Kameramodul eingeben muss.
Kann mir hier vielleicht jemand helfen

[MikePapa]

Vielen Dank für die Zusendung. Die Kameras funktionieren in der Cloud nicht mehr, weil sie mit einer lokalen IP-Adresse hinterlegt sind. Auch in vorherigen Versionen hätte diese Methode nur zuhause, also im heimischen WLAN, funktioniert, nicht jedoch von unterwegs.

Ab airStudio 9.3 wird diese Methode von der Cloud nicht mehr unterstützt. Der Grund ist, dass das Web-Interface ab 9.3 eine sog. Progressive Web App ist. Dies bedeutet, dass sich die App wie eine native Android bzw. iOS App verhält, wesentlich schneller lädt und sogar offline-fähig ist. Um dies zu realisieren, muss der gesamte Content per HTTPS zur Verfügung gestellt werden. Da die meisten IP-Kameras nur HTTP unterstützen, werden die Bilder durch einen Server gejagt, welcher diese in HTTPS umwandelt. Das ist natürlich nur dann möglich, wenn der Server auf die Bilder zugreifen kann. Bei Verwendung einer lokalen IP-Adresse funktioniert dies nicht.

Um also in der Cloud wieder Bilder zu sehen, müssen die Kameras per DynDNS Dienst (s. airStudio > Light-Manager Setup > Weiteres) eingebunden werden. Außerdem ist eine Portfreigabe im Router erforderlich. Dann funktioniert der Zugriff von überall und das Cloud Interface ist komplett HTTPS gesichert.

Ich muss hier mal kurz nachhacken, sorry: Die Empfehlung ist, an meinem Router einen weiteren Port zu öffnen, via Portweiterleitung den Zugriff auf meine unverschlüsselt IP Kamera dahinter freizugeben. Das bedeutet, dass via ein Port Scan festgestellt werden kann welche Kamera sich dahinter verbirgt und als nächstes, da unverschlüsselt (outgoing traffic), UserID und PWD abgefangen (oder via Probes, Bots, usw. rausgefunden) werden und irgendwelche Leute auf den Videostream zugreifen können? Ich verstehe, dass dann aus Sicht JBmedia alles verschlüsselt ist - aber bis es mal bei deren Servern ist... Ich erinnere mich an einen Beitrag aus Stern-TV vor einigen Jahren, bei denen Familien besucht wurden, die solche Kameras freigeschaltet hatten.

Ich nutze ebenfalls das Cloud Interface und wenn ich Live Bilder sehen wollte öffnete ich einen VPN Tunnel. Während das Webinterface offen war, wurden die Kamerabilder dargestellt sobald das VPN zustande gekommen war. Das war 2 Swipe mit dem Handy oder Mac/PC sehr komfortabel und sicher.

Oder sehe ich da etwas falsch? Bitte mich aufschlauen bin gerade verwirrt...

Gruss,
Marcel

[jbmedia]

Die eigentliche Problematik ist Folgende: Google (und auch Apple) verlangt zunehmend, dass alle Inhalte per HTTPS geliefert werden. Das bisherige Web-Interface war, wenn man es auf den Homescreen legte, eine sog. Web-App, also praktisch "nur" eine Verknüpfung mit einer Webseite. Bei dieser Methode drückt Google noch ein Auge zu und erlaubt das Laden von Bildern über HTTP. Es ist allerdings eine Frage der Zeit, wann das nicht mehr akzeptiert wird.

Das neue Web-Interface ist eine sog. Progressive Web-App (PWA). Diese verhält sich wie eine native App und bietet einige Vorteile, z.B. werden alle Daten lokal gepuffert, wodurch es immer blitzschnell lädt, sogar wenn man offline ist. PWAs sind die Zukunft, da die meisten Features eines Smartphones nutzbar sind. so könnte man das Web-Interface per Fingerprint-Reader sichern oder Mitteilungen vom Light-Manager empfangen. Bei PWAs gibt es aber keine Ausnahmeregelung, alles muss über HTTPS kommen. Insofern wüssten wir derzeit keine andere Möglichkeit, als die Kamerabilder per Server von HTTP nach HTTPS zu wandeln, wozu ein Zugriff auf die Kamera von außen möglich sein muss. Bei der VPN Methode bleiben die Bilder aus Sicht des Browsers HTTP Elemente und werden daher geblockt.

Was wir anbieten können, wäre ein alternativer Cloud Zugang, der wie bisher als klassische Verknüpfung auf den Homescreen gelegt werden kann. Dabei stehen die PWA Vorteile nicht zur Verfügung, die Kamerabilder könnten aber über HTTP geladen werden.

[MikePapa]

Die eigentliche Problematik ist Folgende: Google (und auch Apple) verlangt zunehmend, dass alle Inhalte per HTTPS geliefert werden. Das bisherige Web-Interface war, wenn man es auf den Homescreen legte, eine sog. Web-App, also praktisch "nur" eine Verknüpfung mit einer Webseite. Bei dieser Methode drückt Google noch ein Auge zu und erlaubt das Laden von Bildern über HTTP. Es ist allerdings eine Frage der Zeit, wann das nicht mehr akzeptiert wird.

Das neue Web-Interface ist eine sog. Progressive Web-App (PWA). Diese verhält sich wie eine native App und bietet einige Vorteile, z.B. werden alle Daten lokal gepuffert, wodurch es immer blitzschnell lädt, sogar wenn man offline ist. PWAs sind die Zukunft, da die meisten Features eines Smartphones nutzbar sind. so könnte man das Web-Interface per Fingerprint-Reader sichern oder Mitteilungen vom Light-Manager empfangen. Bei PWAs gibt es aber keine Ausnahmeregelung, alles muss über HTTPS kommen. Insofern wüssten wir derzeit keine andere Möglichkeit, als die Kamerabilder per Server von HTTP nach HTTPS zu wandeln, wozu ein Zugriff auf die Kamera von außen möglich sein muss. Bei der VPN Methode bleiben die Bilder aus Sicht des Browsers HTTP Elemente und werden daher geblockt.

Was wir anbieten können, wäre ein alternativer Cloud Zugang, der wie bisher als klassische Verknüpfung auf den Homescreen gelegt werden kann. Dabei stehen die PWA Vorteile nicht zur Verfügung, die Kamerabilder könnten aber über HTTP geladen werden.

Danke für die klärenden Worte, ich verstehe den Punkt. Sehr löblich wenn sich JBMedia Gedanken dazu macht, eine zweite Web Interface Infrastruktur zu betreiben um bestehende IP Kameras doch noch zu nutzen!

Auf der anderen Seite macht es Sinn dass ich (wir) mit der Entwicklung mitgehen. Dann stelle ich mal die "alten" HTTP IP Kameras in Frage bei mir... Ein brennender Punkte dazu:

- Was wären altervative Indoor Kameras die in die PWA's eingebunden werden können (Ich habe momentan Foscam C2)?

Gruss,
Marcel