FHEMWeb Verlängerung der Anmeldung über Cookie - FHEMWeb-Patch

[viegener]

Einige Geräte (insbesondere iOS_DEvices) haben die Eigenschaft, dass sie bei basicauth-Anmeldung nichtmal den Benutzer vorbelegen aus der letzten Anmeldung. Ich hatte schon länger überlegt, ob man nicht dafür einen Loginscreen bauen sollte, allerdings wäre das eine relativ aufwändige Umbauarbeit.

Die Lösung die ich gebaut habe schickt nach erfolgreicher Anmeldung ein Cookie mit dem Authttoken, dass zur Anmeldung für eine einstellbare Zeit verwendet wird. Während dieser Zeit (in Tagen) wird keine weitere Anmeldung erforderlich. Es gibt dazu ein zusätzliches Attribute

cookieExpiryDays in dem die Laufzeit des Cookies in Tagen angegeben werden kann. Default 0 also kein Cookie (wie bisher).
Der Cookie wird nur bei erfolgreicher Anmeldung gesetzt und eingestellter Dauer gesetzt, ansonsten entsteht keine Veränderung.

Der Patch gegen die aktuellste Version von FHEMWeb (ID 10264 von gestern) findet sich anbei.
@Rudi: Ein paar Debug-Ausgaben habe ich noch dringelassen...

Gruss,
Johannes

[rudolfkoenig]

Da der Patch groesser ist, und sein Sinn mir nicht direkt einleuchtet: besteht auch bei anderen Interesse?

[peterchen89]

Ein ähnliches Problem habe ich auch. Verwende aber einen Apache Reverse Proxy mit HTTPS und basic auth vor FHEM. Meine Idee zur Lösung war einen Pfad für jeden Benutzer über den er dann automatisch authentifiziert ist. Quasi eine dauerhafte Session in der URL. Wäre das nicht auch eine praktikable Lösung?

Zumindest mir gibt es ein besseres Gefühl die Zugangsmöglichkeiten über Apache und nicht über FHEM direkt zu verwalten. 

[viegener]

Ein ähnliches Problem habe ich auch. Verwende aber einen Apache Reverse Proxy mit HTTPS und basic auth vor FHEM. Meine Idee zur Lösung war einen Pfad für jeden Benutzer über den er dann automatisch authentifiziert ist. Quasi eine dauerhafte Session in der URL. Wäre das nicht auch eine praktikable Lösung?

Zumindest mir gibt es ein besseres Gefühl die Zugangsmöglichkeiten über Apache und nicht über FHEM direkt zu verwalten.

Generell könnte man das wohl über einen Apache Reverse Proxy abbilden, allerdings erhöht das deutlich die Komplexität. Ausserdem verhindert es auch Probleme von Anfängern  bei mir nachstellen oder debuggen zu können. Dafür wird häufig der direkte Zugriff von Browser auf FHEMWEB benötigt. Gerade im Zusammenhang mit Extensions unter HTTPSRV (z.B. mit FTUI) tauchen bei den Benutzern immer wieder interessante Effekte auf.

Wie gesagt generell fände ich eine Login-Seite mit Session-Cookie eine noch bessere Lösung, aber der Session-Cookie nach erfolgter Anmeldung per basic-Auth ist schon eine recht gute Annäherung und trotzdem auch eine überschaubare Erweiterung. Mir ging es ja auch darum etwas zu machen was das Verhalten für diejenigen, die das nicht brauchen auch nicht verändert. Ich habe es deshalb so gebaut, dass nichtmal eine Cookie gesetzt wird, wenn das Attribut nicht gesetzt ist.

[slor]

Ich finde die Idee super! Reverse Proxy ist zu kompliziert.
Mein Windows 10 Phone erfragt auch bei jeder Anmeldung nach user und pw. Total nervig.

[micomat]

wäre ein Grund weniger für "Lieschen Müller" die Basic auth einfach weg zu lassen. siehe Security Thread in sonstiges.

[rudolfkoenig]

Ich gehe davon aus, dass mit der neuen Modularisierung der Authentifizierung diese Loesung auch in einem externen Modul ausgelagert werden kann. Als Beispiel kann man allowed_Authenticate in 96_allowed.pm nehmen, und von da ist auch nur der Abschnitt fuer FHEMWEB relevant, telnet muss ja nicht unterstuetzt werden.

[viegener]

Geht leider doch nicht so einfach --> siehe hier http://forum.fhem.de/index.php/topic,46380.msg381773.html#msg381773