Bei meinem IPhone (iOS 18.4.1) kommt im Safari trotz attr basicAuthExpiry im FHEMWEB bei jedem Aufruf die Abfrage nach Username Passwort im Safari. Früher ging das, scheint an neuer iOS-Version zu liegen.
Fhem-seitig scheint basicAuthExpiry korrekt konfiguriert zu sein, da lastAuthExpiresFmt in der Zukunft liegt.
Ich möchte mein fhem mit Username/Passwort absichern, aber nicht bei jedem Aufruf auf dem Handy mein Passwort eingeben.
Hat jemand eine Idee, wie man das lösen kann - ggf. auch mit anderen Lösungen als basicAuthExpiry?
Speichern des Passworts im Safari funktioniert auch nicht.
Ich konnte das Problem auf einem iPad weder unter 18.3 noch unter 18.4.1 nachstellen.
Guten Morgen!
Ich habe das selbe Problem! Vor dem IOS Update ging es problemlos. Man musste sich einmal anmelden und war angemeldet, teilweise über mehrere Tage ohne erneute pwd Eingabe.
Seit dem Update muss ich mich erneut anmelden, teilweise sogar wenn ich einen anderen room anwähle oder sogar zwei mal im gleichen room.
Gruss
Felix
Ich kann das gerne naeher untersuchen (und falls moeglich fixen), wenn man mir eine genaue Anleitung samt fhem.cfg Beispiel zeigt. Ich habe es (wie oben erwaehnt) versucht nach der groben Beschreibung nachzustellen, ohne Erfolg.
Ich glaube ich weiss wo das Problem herkommt. Ich bin immer mit dem iPhone über FHEMWEB rein. Nachdem ich WEBphone gesetzt habe und darüber rein gehe, funktioniert es. (Ausser der f18 style)
Hilft das weiter?
Hilft das weiter?Mir nicht.
WEBphone ist seit f18 und damit seit 7 Jahren Geschichte.
So sehr es mich freut, dass es einen Workaround gibt, ich will das eigentliche Problem fixen.
Seit dem Update auf 18.4 sehe ich auch das von FhemPiUser beschriebene Verhalten bei Zugriff mit Safari von meinem iPhone oder iPad auf meine FHEMWEB Instanz. Das 'expiry' Datum für die Authentifizierung liegt bei mir auch in der Zukunft.
Safari 18.4 auf dem MacBook verhält sich ähnlich, wenn man in der Dialogbox zum Anmelden keinen Haken in der Checkbox "dieses Passwort merken" setzt. Auf dem iPhone und iPad wird mir diese Checkbox nicht angezeigt. Im "privaten" Surfen auf dem MacBook fehlt die Checkbox ebenfalls und der Passwortdialog erscheint ständig.
Über Chrome funktioniert der Zugriff von allen Geräten wie gehabt.
Zum Reproduzieren: fhem in neuem Safari-Profil oder nach Löschen der Webseitendaten/des AuthToken Cookies aufrufen, so dass initial eine Passworteingabe erforderlich ist. Nach dieser initialen Eingabe funktioniert das UI erstmal wie gewohnt, nach ca. 60 s erscheint dann die Passwortabfrage 'ständig' z.B. beim Aufruf eines anderen Raumes. Den Passwortdialog kann man ohne Eingabe Username/Passwort über Abbrechen oder Anmelden wegklicken, die Seite des Raumes wird trotzdem angezeigt.
Habe andere Einstellungen für longpoll, closeConn etc. probiert, allerdings ohne Erfolg. Kann gerne auch logs liefern.
Mein WEB Device:
Internals:
BYTES_READ 38466307
BYTES_WRITTEN 3475213671
CONNECTS 122511
CSRFTOKEN csrf_216648203983122
DEF 8083 global
FD 7
FUUID 62d65031-f33f-591b-382f-5e86181eea3d9283
NAME WEB
NR 31
NTFY_ORDER 50-WEB
PORT 8083
SSL 1
STATE Initialized
TYPE FHEMWEB
eventCount 13
READINGS:
2025-05-05 09:11:02 state Initialized
hmccu:
Attributes:
DbLogExclude .*
HTTPS 1
JavaScripts codemirror/fhem_codemirror.js
SVGcache 0
alias WEB
closeConn 0
confirmDelete 0
csrfTokenHTTPHeader 1
fwcompress 1
jsLog 0
longpoll websocket
plotEmbed 0
sslVersion TLSv12:!SSLv3
stylesheetPrefix dark
verbose 5
Mein allowed Device (hash unkenntlich gemacht):
Internals:
FUUID 63c4248e-f33f-ce32-c1b3-d2bfa0bb6f0cdcce
NAME allowedWEB
NR 532
STATE validFor:WEB
TYPE allowed
eventCount 60609
READINGS:
2025-05-07 10:12:30 lastAuthExpires 1789805550
2025-05-07 10:12:30 lastAuthExpiresFmt Sat, 19 Sep 2026 08:12:30 GMT
2025-05-07 10:12:30 lastAuthUser admin
2025-05-05 09:11:23 state validFor:WEB
hmccu:
Attributes:
DbLogExclude .*
allowedIfAuthenticatedByMe 1
basicAuth SHA256:xxxx:xxxx
basicAuthExpiry 500
validFor WEB
verbose 5
Ich habe jetzt ein fhem.cfg mit der oben genannten WEB und allowedWEB Definition angelegt, hatte aber keine Probleme.
Natuerlich habe ich vorher ein Passwort gesetzt, und vor dem ersten Aufruf auf dem iPad (iOS 18.4.1) in den Einstellungen die Safari Browserhistorie komplett entfernt.
Ich musste beim Aufruf der FHEM Seite auf dem iPad einmal Benutzername/Passwort eingeben, und konnte ca 15 Minuten lang auf der Seite "herumsurfen", ohne noch einmal Passwort eingeben zu muessen.
Auch ein ins Hintergrund schicken des Browsers hat nichts geaendert.
Danach habe ich das Interesse verloren :)
P.S.: Bitte das naechste mal "list -r" oder "Raw definition" fuer die Vorlage verwenden, spart mir Arbeit beim Nachstellen.
@rudolfkoenig Ein Nachstellen ist in der Tat nicht so einfach. Ich habe jetzt teilweise auch lange (>1h) gebraucht, um den fehlerhaften Zustand zu bekommen. Der "Kipppunkt" korreliert mit dem ersten Abruf von Icons (favicon.ico, apple-touch-icon.png, apple-touch-icon-precomposed.png) seitens des Clients. Nach dem Kipppunkt kommt der Passwortdialog dann "häufig".
Einer Passwortabfrage geht folgende Anfrage des Clients voraus (hier für favicon):
2025.05.13 11:14:58 5: GET /fhem/icons/favicon HTTP/1.1
Host: 192.168.67.247:8083
User-Agent: NetworkingExtension/8621.2.5.10.10 Network/4277.122.6 iOS/18.5
Accept: */*
Accept-Language: de-DE,de;q=0.9
Priority: u=7, i
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Nach Passworteingabe erfolgt die Abfrage des Icons dann mit der Authorization Info:
2025.05.13 11:16:47 4: WEB_192.168.67.68_56650 GET /favicon.ico; BUFLEN:0
2025.05.13 11:16:47 5: GET /fhem/icons/favicon HTTP/1.1
Host: 192.168.67.247:8083
User-Agent: NetworkingExtension/8621.2.5.10.10 Network/4277.122.6 iOS/18.5
Accept: */*
Accept-Language: de-DE,de;q=0.9
Priority: u=7, i
Accept-Encoding: gzip, deflate, br
Authorization: Basic #####################
Connection: keep-alive
Der Abruf des Icons erfolgt mit einem anderen User-Agent, als der Aufruf eines Raumes. Dieser "User-Agent: NetworkingExtension/8621.2.5.10.10 Network/4277.122.6 iOS/18.5)" kennt scheinbar das Authorization hash nicht (persistent). Safari auf dem Mac liefert übrigens für den Abruf Icons die Authorization gleich mit, daher keine Passwortabfrage und kein Problem (auch unter macOS 15.5).
Ich hoffe, meine Beobachtung hilft etwas weiter...
ZitatIch hoffe, meine Beobachtung hilft etwas weiter...
Ich habe zwar was dazugelernt, aber noch keine gute Idee, wie man das Problem loesen soll.
Soll FHEM fuer Bilder keine Zugangspruefung durchfuehren?
War dein Testgeraet iPad oder iPhone?
Die Tests habe ich mit iPhone und iPad durchgeführt, beide mittlerweile auf iOS 18.5.
Die Lösung wäre, wenn der NetworkingExtension-Helper auf dem iPhone und iPad die Authentifizierungsdetails kennen würde. Da haben wir aber wohl keinen Einfluss drauf.
Ein für mich akzeptabler Workaround ist, die Anfrage nach diesen Icons nicht mehr zu bedienen. Dazu habe ich mein 01_FHEMWEB.pm angepasst.
Es werden folgende Icons angefragt:
2025.05.13 10:23:28 5: GET /apple-touch-icon-precomposed.png HTTP/1.1
2025.05.13 10:23:28 5: GET /apple-touch-icon.png HTTP/1.1
2025.05.13 10:23:28 5: GET /favicon.ico HTTP/1.1
2025.05.13 10:23:28 5: GET /fhem/icons/favicon HTTP/1.1
Die Anfrage nach /fhem/icons/favicon habe ich eliminiert, indem es nicht mehr "beworben" wird, d.h. folgende Zeile habe ich auskommentiert:
#FW_pO '<link rel="shortcut icon" href="'.FW_IconURL("favicon").'" />';
Die ersten drei Icons in der Liste werden ja im root Verzeichnis des Servers angefragt. Ich lasse jetzt nur noch http Anfragen zu, deren URL mit $FW_ME beginnen und natürlich explizit "/". Alle anderen Anfragen werden mit 404 beantwortet. Damit bin ich die Passwort-Abfragen los uns sehe bisher keine Seiteneffekte.
Die Prüfung der URL erfolgt vor der Prüfung nach gültigen Methoden:
#########################
# Check URL to allow only "/" and URL starting with $FW_ME
my ($method, $arg, $httpvers) = split(" ", $FW_httpheader[0], 3)
if($FW_httpheader[0]);
if ((rindex $arg,$FW_ME,0)&&($arg ne "/")) {
Log3 $FW_wname, 1, "[cawe] arg: $arg does not start with $FW_ME and is not /";
my $retCode = "404 Not Found";
TcpServer_WriteBlocking($FW_chash,
"HTTP/1.1 $retCode\r\n" .
$FW_headerlines.
"Content-Length: 0\r\n\r\n");
delete $hash->{CONTENT_LENGTH};
FW_Read($hash, 1) if($hash->{BUF});
FW_closeConn($hash);
return;
}
#########################
# Return 200 for OPTIONS or 405 for unsupported method
# ab hier unverändert
$method = "" if(!$method);
my $ahm = AttrVal($FW_wname, "allowedHttpMethods", "GET|POST");
if($method !~ m/^($ahm)$/i){
my $retCode = ($method eq "OPTIONS") ? "200 OK" : "405 Method Not Allowed";
TcpServer_WriteBlocking($FW_chash,
"HTTP/1.1 $retCode\r\n" .
$FW_headerlines.
"Content-Length: 0\r\n\r\n");
delete $hash->{CONTENT_LENGTH};
FW_Read($hash, 1) if($hash->{BUF});
Log 3, "$FW_cname: unsupported HTTP method $method, rejecting it."
if($retCode ne "200 OK");
FW_closeConn($hash);
return;
}
Danke für die Analyse und Lösungsvorschläge. Wäre das etwas, was in eines der nächsten FHEM-Updates kommt oder sollte man die FHEMWEB manuell anpassen?
ZitatDie ersten drei Icons in der Liste werden ja im root Verzeichnis des Servers angefragt. Ich lasse jetzt nur noch http Anfragen zu, deren URL mit $FW_ME beginnen und natürlich explizit "/". Alle anderen Anfragen werden mit 404 beantwortet. Damit bin ich die Passwort-Abfragen los uns sehe bisher keine Seiteneffekte.
Da ich nicht so sicher bei den Seiteneffekten bin, habe ich einen Alternativvorschlag:
mit dem noCheckFor allowed Attribut kann man ab sofort die URLs spezifizieren, fuer die man keine Authentifizierung wuenscht.
Fuer die beobachteten Dateien waere das
attr allowed noCheckFor ^(/[^/]+|/fhem/icons/favicon)$
Danke für deinen Vorschlag und die schnelle Umsetzung! Das beschriebene Problem mit den Passwortabfragen tritt damit bei mir nicht mehr auf.
Es werden, wie gehabt, die vier Icons abgerufen, favicon doppelt und die beiden apple-touch-icons...
2025.05.17 16:51:37 5: GET /apple-touch-icon-precomposed.png HTTP/1.1
2025.05.17 16:51:37 4: WEB_192.168.67.143_62275 GET /apple-touch-icon-precomposed.png; BUFLEN:0
2025.05.17 16:51:37 4: WEB: redirecting /apple-touch-icon-precomposed.png to /fhem
2025.05.17 16:51:37 5: GET /apple-touch-icon.png HTTP/1.1
2025.05.17 16:51:37 4: WEB_192.168.67.143_62276 GET /apple-touch-icon.png; BUFLEN:0
2025.05.17 16:51:37 4: WEB: redirecting /apple-touch-icon.png to /fhem
2025.05.17 16:51:38 5: GET /favicon.ico HTTP/1.1
2025.05.17 16:51:38 4: WEB_192.168.67.143_62277 GET /favicon.ico; BUFLEN:0
2025.05.17 16:51:38 5: GET /fhem/icons/favicon HTTP/1.1
2025.05.17 16:51:38 4: WEB_192.168.67.143_62278 GET /fhem/icons/favicon; BUFLEN:0
Die beiden Icons, apple-touch-icon.png und apple-touch-icon-precomposed.png werden nicht unter ./www und ./www/images/default/ gefunden, obwohl ich dort passende abgelegt hatte. Die Abfrage resultiert daher in einer Weiterleitung auf /fhem. Mache ich da etwas falsch?
Zum Testen hatte ich noch zwei serveSpecial Fälle analog zu favicon in FHEMWEB eingefügt, damit zumindest die Icons ausgeliefert werden. Wo diese Icons dann sichtbar werden ist mir allerdings unklar. Beim Ablegen eines Lesezeichens auf dem Homescreen jedenfalls nicht.
Zitat von: rudolfkoenig am 17 Mai 2025, 11:38:55ZitatDie ersten drei Icons in der Liste werden ja im root Verzeichnis des Servers angefragt. Ich lasse jetzt nur noch http Anfragen zu, deren URL mit $FW_ME beginnen und natürlich explizit "/". Alle anderen Anfragen werden mit 404 beantwortet. Damit bin ich die Passwort-Abfragen los uns sehe bisher keine Seiteneffekte.
Da ich nicht so sicher bei den Seiteneffekten bin, habe ich einen Alternativvorschlag:
mit dem noCheckFor allowed Attribut kann man ab sofort die URLs spezifizieren, fuer die man keine Authentifizierung wuenscht.
Fuer die beobachteten Dateien waere das
attr allowed noCheckFor ^(/[^/]+|/fhem/icons/favicon)$
Bei mir ist damit jetzt auch das Problem behoben. Ich setzte das Thema auf gelöst.
Vielen Dank für die schnelle und elegante Lösung Rudolf!
ZitatDie beiden Icons, apple-touch-icon.png und apple-touch-icon-precomposed.png werden nicht unter ./www und ./www/images/default/ gefunden, obwohl ich dort passende abgelegt hatte.
Es gibt keinen Weg, diese Pfade per FHEMWEB auszuliefern, Bilder muessen per /fhem/icons/iconnname (hier greift iconPath) oder direkt per /fhem/images/default/iconname.png referenziert werden.
f18.js fuegt fuer diesen Zweck eine Zeile zum Header hinzu:
<link rel="apple-touch-icon" href="/fhem/images/default/fhemicon_ios.png">ZitatWo diese Icons dann sichtbar werden ist mir allerdings unklar
Wenn ich mich recht erinnere, sind beide Dateien fuer die Anzeige auf dem Desktop.
Die precomposed Variante enthaelt das Bild mit dem Rechteck dahinter, bei der anderen Variante baut iOS aus Rechtek und Icon das endgueltige Bild zusammen.