96_allowed.pm - verschiedene komische Verhalten

Begonnen von betateilchen, 20 Januar 2017, 17:36:15

Vorheriges Thema - Nächstes Thema

betateilchen

Bei Experimentieren mit 96_allowed.pm sind mir ein paar merkwürdige Dinge aufgefallen.

per telnet habe ich folgendes device angelegt:


Internals:
   CFGFN     
   NAME       allowedWeb
   NR         64
   STATE      active
   TYPE       allowed
   validFor   web
   Readings:
     2017-01-20 17:22:51   state           active
Attributes:
   basicAuth  { myAuth($user,$password) == 1 }



  • wenn ich in der telnet Session jetzt versuche, ein "attr allowedWeb validFor web" auszuführen, wird die telnet-Verbindung sofort beendet und das Attribut nicht gesetzt.
  • myAuth() wird nicht aufgerufen, wenn $user und/oder $password keine Werte enthält (wenn man das leere Anmeldepopup abschickt). Es kommt dann nur noch ein weißer Bildschirm.

Wunschliste/Fragen:


  • basicAuthExpiry sollte kürzere Zeiträume zulassen, nicht nur Tage.
  • ich würde gerne irgendwie einfach herausfinden, wie lange meine basicAuth noch valid ist (=Restlaufzeit von basicAuthExpiry)
  • ich verstehe noch nicht, wie das Setzen von Attributen per CommandAttr() von allowed.pm beeinflußt wird. Es ist mir noch nicht gelungen, ein Attribut aus meiner Funktion myAuth() zu setzen. (das direkte Beschreiben von %attr funktioniert natürlich, will ich aber vermeiden) - funktioniert -
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

1. habs versucht nachzustellen, bei mir ist alles in Ordnung. Telnet stuerzt nicht ab, WEB fragt nach Passwort. Was ich dabei entdeckt habe: basicAuth mit "attr WEB longpoll websocket" funktioniert nicht. Habe auch noch keine Idee, wie ich das fixen soll, sollte aber fuer deinen Fall irrelevant sein.

Nach weiteren Experimentieren: das Setzen von basicAuth entfernt ueberall das Authenticated flag, was zum Beenden der telnet Verbindung gefuehrt hat. Das habe ich jetzt gefixt, ein unmotiviertes telnet-IAC kommt aber weiterhin

2. laut Programmcode ist das nicht der Fall:
  my ($user, $password) = split(":", decode_base64($secret));
  $pwok = eval $basicAuth;

und auch die Debug-Ausgabe nach einem Test zeigt was anderes.

ZitatbasicAuthExpiry sollte kürzere Zeiträume zulassen, nicht nur Tage.
Das hat Johannes verbrochen (https://forum.fhem.de/index.php/topic,46380.msg383262.html#msg383262), wie svn blame und log es mir gerade verraten hat. Ich habe mal das int() ein paar Zeilen weiter nach unten geschoben, damit kann man jetzt auch Tage als Fliesskomma definieren.

Zitatich würde gerne irgendwie einfach herausfinden, wie lange meine basicAuth noch valid ist (=Restlaufzeit von basicAuthExpiry)
Da es als Cookie gespeichert wird, findet man den Ablaufdatum beim Anschauen des Cookies im Browser. Einen anderen Weg kenne ich nicht.

betateilchen

Zitat von: rudolfkoenig am 21 Januar 2017, 14:26:57
Ich habe mal das int() ein paar Zeilen weiter nach unten geschoben, damit kann man jetzt auch Tage als Fliesskomma definieren.

Mir schwebt ja eher sowas vor wie


attr <name> basicAuthExpiry 3d5h4m


(oder Teile davon) um beispielsweise auch ein expiry von 30 Minuten setzen zu können, ohne erst einen Taschenrechner bemühen zu müssen.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

#3
Zitat von: betateilchen am 20 Januar 2017, 17:36:15
ich würde gerne irgendwie einfach herausfinden, wie lange meine basicAuth noch valid ist (=Restlaufzeit von basicAuthExpiry)

Zitat von: rudolfkoenig am 21 Januar 2017, 14:26:57
Da es als Cookie gespeichert wird, findet man den Ablaufdatum beim Anschauen des Cookies im Browser. Einen anderen Weg kenne ich nicht.

Man könnte beispielsweise ein Internal befüllen (wahlweise natürlich auch ein reading)

Man könnte readings erzeugen und damit auch gleich den angemeldeten user verfügbar machen.


Index: 96_allowed.pm
===================================================================
--- 96_allowed.pm (Revision 13191)
+++ 96_allowed.pm (Arbeitskopie)
@@ -108,6 +108,7 @@
     }
     
     my $pwok = ($secret && $secret eq $basicAuth);      # Base64
+    my ($user, $password);
     if($secret && $basicAuth =~ m/^{.*}$/) {
       eval "use MIME::Base64";
       if($@) {
@@ -114,7 +115,7 @@
         Log3 $aName, 1, $@;

       } else {
-        my ($user, $password) = split(":", decode_base64($secret));
+        ($user, $password) = split(":", decode_base64($secret));
         $pwok = eval $basicAuth;
         Log3 $aName, 1, "basicAuth expression: $@" if($@);
       }
@@ -127,6 +128,8 @@
         $time = int($time*86400+time());
         # generate timestamp according to RFC-1130 in Expires
         my $expires = "Expires=".FmtDateTimeRFC1123($time);
+readingsSingleUpdate($me,'authUser',$user,0);
+readingsSingleUpdate($me,'authExpires',$time,0);
         # set header with expiry
         $cl->{".httpAuthHeader"} = "Set-Cookie: AuthToken=".$secret.
                 "; Path=/ ; ".$expires."\r\n" ;


-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Hab dein Patch leicht modifziert eingecheckt. Bitte beachten: die readings gelten nur fuer die letzte Authentifizierung, man kann aber in mehreren Browser den gleichen Benutzer angeben.

betateilchen

ich bin auch noch nicht so ganz sicher, ob die readings wirklich die bessere Variante gegenüber Internals sind, denn die readings werden ja auch mit abgespeichert *nachdenk*
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!