[gelöst] Problem mit basicAuthExpiry und iOS Safari

[FhemPiUser]

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.

[rudolfkoenig]

Ich konnte das Problem auf einem iPad weder unter 18.3 noch unter 18.4.1 nachstellen.

[dichter04]

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

[rudolfkoenig]

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.

[dichter04]

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?

[rudolfkoenig]

Code Auswählen Erweitern

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.

[cawe]

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:

Code Auswählen Erweitern

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):

Code Auswählen Erweitern

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

[rudolfkoenig]

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.

[cawe]

@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):

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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

[rudolfkoenig]

Ich 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?

[cawe]

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

#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:

Code Auswählen Erweitern

#########################
  # 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;
  }
 

[FhemPiUser]

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?

[rudolfkoenig]

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.

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

Code Auswählen Erweitern

attr allowed noCheckFor ^(/[^/]+|/fhem/icons/favicon)$


[cawe]

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.

[FhemPiUser]

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.

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

Code Auswählen Erweitern

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!