NEWS
Fehler Admin auf Ipad nach Update
-
@homoran sagte in Fehler Admin auf Ipad nach Update:
@markus84 sagte in Fehler Admin auf Ipad nach Update:
Wenn es eine einfache und leicht wieder rückgängig zu machende Möglichkeit gegeben hätte, hätte ich es einfach nur mal ausprobiert.
gibt es doch!
admin-Instanz - Konfiguration - Haupteinstellungen - Checkbox https benutzenich glaube, das war doch der Ausgangspunkt dieses Threads - scheint so, als gäbe es bei dieser "Sorte https" inzwischen/derzeit/nach den letzten Updates Probleme mit IOS-Geräten. Die offenbar nicht bei https mit "richtigen" Certs auftreten...
@jleg @Homoran Um da doch noch konstruktiv BTT beizutragen. Ich habe mit dem IPhone bei mir bei keinem Gerät/keinem meiner Webdienste Zugriffsprobleme. Weder bei denen ohne https, als auch bei denen, die Zugriff von außen haben. Die haben alle Zertifikate von Letsencrypt, natürlich passend zur jeweiligen Subdomain.
Wenn iobroker da mit Letsencrypt-Zertifikaten nicht läuft, dann scheint es zumindest was "iobroker-spezifisches" zu sein und nicht generell an "eigenen" Letsencrypt-Zertifikaten zu liegen.Gruss, Jürgen
-
@jleg @Homoran Um da doch noch konstruktiv BTT beizutragen. Ich habe mit dem IPhone bei mir bei keinem Gerät/keinem meiner Webdienste Zugriffsprobleme. Weder bei denen ohne https, als auch bei denen, die Zugriff von außen haben. Die haben alle Zertifikate von Letsencrypt, natürlich passend zur jeweiligen Subdomain.
Wenn iobroker da mit Letsencrypt-Zertifikaten nicht läuft, dann scheint es zumindest was "iobroker-spezifisches" zu sein und nicht generell an "eigenen" Letsencrypt-Zertifikaten zu liegen.Gruss, Jürgen
@wildbill sagte in Fehler Admin auf Ipad nach Update:
@jleg @Homoran Um da doch noch konstruktiv BTT beizutragen. Ich habe mit dem IPhone bei mir bei keinem Gerät/keinem meiner Webdienste Zugriffsprobleme. Weder bei denen ohne https, als auch bei denen, die Zugriff von außen haben. Die haben alle Zertifikate von Letsencrypt, natürlich passend zur jeweiligen Subdomain.
Wenn iobroker da mit Letsencrypt-Zertifikaten nicht läuft, dann scheint es zumindest was "iobroker-spezifisches" zu seinsorry, im Thread ging's doch genau darum - mit Letsencrypt keine Probleme, mit Default-HTTPS offenbar zumindest beim TO Probleme...
-
@wildbill sagte in Fehler Admin auf Ipad nach Update:
@jleg @Homoran Um da doch noch konstruktiv BTT beizutragen. Ich habe mit dem IPhone bei mir bei keinem Gerät/keinem meiner Webdienste Zugriffsprobleme. Weder bei denen ohne https, als auch bei denen, die Zugriff von außen haben. Die haben alle Zertifikate von Letsencrypt, natürlich passend zur jeweiligen Subdomain.
Wenn iobroker da mit Letsencrypt-Zertifikaten nicht läuft, dann scheint es zumindest was "iobroker-spezifisches" zu seinsorry, im Thread ging's doch genau darum - mit Letsencrypt keine Probleme, mit Default-HTTPS offenbar zumindest beim TO Probleme...
@jleg Ach so, sorry, das kommt davon, wenn man zwischendrin einsteigt. Asche auf mein Haupt.
Dann könnte ich mir zumindest vorstellen, dass die Domain im Zertifikat nicht der aufgerufenen Adresse entspricht und ios da blockiert. Wobei Chrome und Firefox dann aber auch meckern müssten.Gruß, Jürgen
-
@jleg Das sehe ich bei mir nicht in der Definition Sicherheitswarnung, sondern eben als (Sicherheits-)Hinweis. Warnung ist, wenn ich irgendwas anklicken, weglicken, bestätigen oder Ähnliches muss. Und das habe ich eben maximal dann, wenn ich per https auf eine Seite zugreife, bei der das Zertifikat nicht passt.
Also, warum sich das Leben unnötig schwer machen? Sichert das gut und vor Allem per sauberem Zertifikat ab, was von außen erreichbar sein muss, macht auch nur das von außen erreichbar was unbedingt direkt erreichbar sein muss, leitet alles andere durch ein VPN oder schaltet wenigstens einen Reverse Proxy davor und macht ansonsten alles zu, was von außen nicht erreicht werden soll. Und dazu zähle ich auch alle Webinterfaces der internen Geräte, sei es iobroker, CCU, FHEM, Home assistant, Sat-Receiver, Spülmaschine,... Sowas gehört einfach nicht direkt via Portfreigabe ins Internet.
Wobei man da nun zu Recht nach dem Sinn fragen könnte, warum iobroker es dann anbietet, das Webinterface per https und User/Password "abzusichern". Mir fällt da grad kein direkter use case ein. Aber, ich brauche es nicht und kann nur jedem davon abraten.
Gruss, Jürgen@wildbill sagte in Fehler Admin auf Ipad nach Update:
leitet alles andere durch ein VPN oder schaltet wenigstens einen Reverse Proxy davor
ich bin da auch völlig d'accord, was die (nicht-)Notwendigkeiten von Portforwards etc. betrifft - wer's nicht braucht, oder wer nicht weiss, was er tut, sollte es lieber lassen...
Aber was mich schon interessieren würde - inwiefern unterscheidet sich das Ganze mit Revers-Proxy von der Methode "ohne"? :) Ob vor'm Portforward noch ein Proxy hängt, oder nicht, macht doch für' Prinzip erstmal keinen Unterschied, oder? -
@jleg Ach so, sorry, das kommt davon, wenn man zwischendrin einsteigt. Asche auf mein Haupt.
Dann könnte ich mir zumindest vorstellen, dass die Domain im Zertifikat nicht der aufgerufenen Adresse entspricht und ios da blockiert. Wobei Chrome und Firefox dann aber auch meckern müssten.Gruß, Jürgen
@wildbill sagte in Fehler Admin auf Ipad nach Update:
@jleg Ach so, sorry, das kommt davon, wenn man zwischendrin einsteigt. Asche auf mein Haupt.
Dann könnte ich mir zumindest vorstellen, dass die Domain im Zertifikat nicht der aufgerufenen Adresse entspricht und ios da blockiert. Wobei Chrome und Firefox dann aber auch meckern müssten.tun sie auch - aber eben nur einmal, und dann ist gut. Der Safari scheint sich aber offenbar an was anderem zu stossen - leider ist "Debugging" (für mich) bissel schwierig, da man dafür mindestens ein Macbook bräuchte (auf dem iPad geht "Browserkonsole" nur remote mit Macbook).
-
@wildbill sagte in Fehler Admin auf Ipad nach Update:
leitet alles andere durch ein VPN oder schaltet wenigstens einen Reverse Proxy davor
ich bin da auch völlig d'accord, was die (nicht-)Notwendigkeiten von Portforwards etc. betrifft - wer's nicht braucht, oder wer nicht weiss, was er tut, sollte es lieber lassen...
Aber was mich schon interessieren würde - inwiefern unterscheidet sich das Ganze mit Revers-Proxy von der Methode "ohne"? :) Ob vor'm Portforward noch ein Proxy hängt, oder nicht, macht doch für' Prinzip erstmal keinen Unterschied, oder?@jleg Wenn der Reverse proxy korrekt läuft, dann lässt er eben nur Anfragen an genau die Subdomains durch, für die er eingerichtet ist. Pauschale Anfragen an www.domain.de oder direkt per IP-Adresse bringen dann eben einen Fehler oder eine Standard - Site. Ein "Angreifer" müsste also wenigstens noch die korrekte Subdomain erraten/wissen. Wobei ich auch das nicht für iobroker+Co verwenden würde. Wenn, dann VPN.
Gruß, Jürgen -
@jleg Das sehe ich bei mir nicht in der Definition Sicherheitswarnung, sondern eben als (Sicherheits-)Hinweis. Warnung ist, wenn ich irgendwas anklicken, weglicken, bestätigen oder Ähnliches muss. Und das habe ich eben maximal dann, wenn ich per https auf eine Seite zugreife, bei der das Zertifikat nicht passt.
Also, warum sich das Leben unnötig schwer machen? Sichert das gut und vor Allem per sauberem Zertifikat ab, was von außen erreichbar sein muss, macht auch nur das von außen erreichbar was unbedingt direkt erreichbar sein muss, leitet alles andere durch ein VPN oder schaltet wenigstens einen Reverse Proxy davor und macht ansonsten alles zu, was von außen nicht erreicht werden soll. Und dazu zähle ich auch alle Webinterfaces der internen Geräte, sei es iobroker, CCU, FHEM, Home assistant, Sat-Receiver, Spülmaschine,... Sowas gehört einfach nicht direkt via Portfreigabe ins Internet.
Wobei man da nun zu Recht nach dem Sinn fragen könnte, warum iobroker es dann anbietet, das Webinterface per https und User/Password "abzusichern". Mir fällt da grad kein direkter use case ein. Aber, ich brauche es nicht und kann nur jedem davon abraten.
Gruss, Jürgen -
@wildbill sagte in Fehler Admin auf Ipad nach Update:
@jleg Ach so, sorry, das kommt davon, wenn man zwischendrin einsteigt. Asche auf mein Haupt.
Dann könnte ich mir zumindest vorstellen, dass die Domain im Zertifikat nicht der aufgerufenen Adresse entspricht und ios da blockiert. Wobei Chrome und Firefox dann aber auch meckern müssten.tun sie auch - aber eben nur einmal, und dann ist gut. Der Safari scheint sich aber offenbar an was anderem zu stossen - leider ist "Debugging" (für mich) bissel schwierig, da man dafür mindestens ein Macbook bräuchte (auf dem iPad geht "Browserkonsole" nur remote mit Macbook).
@jleg Dann scheint es bei ios wohl so zu sein, dass anstatt einer zusätzlichen Meldung, die man per Bestätigung noch "umgehen" kann, restriktiv einfach blockiert wird.
Vielleicht (vorerst) für den einen oder anderen unerwartet oder hinderlich, aber in meinen Augen muss genau das das Ziel aller Browser werden. Wenn gesicherter Zugriff, dann nur, wenn die gesamte Kette inklusive Zertifikat passt und sicher ist. Sonst könnte man sich https gleich sparen.
Gruß, Jürgen -
@jleg Dann scheint es bei ios wohl so zu sein, dass anstatt einer zusätzlichen Meldung, die man per Bestätigung noch "umgehen" kann, restriktiv einfach blockiert wird.
Vielleicht (vorerst) für den einen oder anderen unerwartet oder hinderlich, aber in meinen Augen muss genau das das Ziel aller Browser werden. Wenn gesicherter Zugriff, dann nur, wenn die gesamte Kette inklusive Zertifikat passt und sicher ist. Sonst könnte man sich https gleich sparen.
Gruß, Jürgen@wildbill sagte in Fehler Admin auf Ipad nach Update:
Dann scheint es bei ios wohl so zu sein, dass anstatt einer zusätzlichen Meldung, die man per Bestätigung noch "umgehen" kann, restriktiv einfach blockiert wird.
"wild guess": da dieses Problem ja nicht nach einem IOS-Update auftrat, sondern nach der Umstellung des iobroker.admin auf V5 mit React, ist das möglicherweise ein Problem im Javascript-Code; hatte ich zufällig so ähnlich vor kurzem mit "VUE" (eine React-Konkurrenz) - eine Anwendung tat's problemlos mit self-signed Zertifikaten, nach einem VUE-Update plötzlich nicht mehr; es lag an internen URL-Aufrufen des ja im Browser laufenden Javascripts, irgendeine der 2000 abhängigen Komponenten mochte keine Selfsigned mehr, Anwendung lief einfach nicht; auch da half dann ein "richtiges" Cert...
-
@nullfreizeit Falls du https nutzt, schalte das mal aus (wie von Thomas vorgeschlagen).
Ich hatte das selbe Problem und konnte es damit lösen.Ich hoffe, dass es auf lange Sicht dafür noch einen Fix gibt, auf dauer will ich nämlich eigentlich nicht mit http unterwegs sein.
@iobroker-lover Da bin ich ganz bei Dir.
Ohne https 'fliegen' meine Login Daten frei im Raum rum.
Sicherlich kann man sagen, dass wenn man sich ausschließlich im heimischen (W)LAN bewegt, dass Risiko ehr Richtung 0 geht, aber es wäre schon hilfreich wenn ergründet wird warum es beim Admin 4 keine Probleme gab und bei Admin 5 schon.Ich habe jetzt natürlich auch temporär https ausgeschaltet, fühle mich dabei aber etwas unwohl und würde es mittelfristig gerne wieder verwenden.
Support us
763
Online32.5k
Benutzer81.8k
Themen1.3m
Beiträge