[PATCH] fhem.pl - Veränderung eines Attribut Values durch AttrFn

[Markus Bloch]

Hallo Rudi,

anbei ein kleiner Patch, der es einer AttrFn ermöglicht den zu prüfenden Wert optional zu verändern.

Das bedeutet im Detail, dass die AttrFn optional als Return Value zwei Werte übergeben. Der zweite Wert ($newvalue) wird dann anstatt des ursprünglich via attr <name> vorgegeben Wertes gespeichert.

Das ganze hat keinerlei Einfluss auf bestehende AttrFn und dem bisherigen Schema mit nur einer optionalen Fehlermeldung als return Value.

Anwendungsszenarien wären bspw:

• z.B. on-the-fly Verschlüsselung von Passwörtern, damit diese nicht im Klartext in der GUI stehen. Das Passwort wird einmal verschlüsselt und kann so durch das Modul dennoch verwendet werden (Das Modul muss natürlich sicher stellen, das ein verschlüsseltes Passwort nicht nochmal verschlüsselt wird)
• abfangen von gängigen Syntaxfehlern und deren direkte Korrektur (z.B. Anführungszeichen oder fehlende Klammern)

Bsp:

Code Auswählen Erweitern

sub xxx_AttrFn(@_)
{

....

# genereller Fehler des Values
return "invalid attribute $val......";

# Value ist generell zwar in Ordnung, muss aber verändert gespeichert werden.
return (undef, $newval);

# value ist in Ordnung (wie gehabt)
return;


}

Ich hoffe das ist so in Ordnung.

Viele Grüße

Markus

[justme1968]

hallo markus,

in meinen modulen mache ich es so das ich den neuen wert direkt in $attr{$name}{$attrName} eintrage wenn ich den wert aus irgendeinem grund noch verändern muss und gebe dann einen passenden text zurück der dann angezeigt wird.

das ist zwar vielleicht etwas umständlicher hat aber den vorteil der sichtbaren meldung.

das würde mit dieser änderung nicht gehen bzw. wenn ich wie bisher etwas anzeigen möchte muss ich es weiter wie bisher machen.

gruss
  andre

[Markus Bloch]

Hallo andre,

ich verstehe gerade nicht ganz deinen Usecase. Bisher ist es ja so, dass wenn man in der AttrFn einen Wert prüft, so kann man den zwar durchaus direkt in $attr{$name}{$attrName} schreiben, aber wird dieser Wert nach erfolgreichen Ende der AttrFn eh wieder mit dem originalen Wert überschrieben (siehe fhem.pl):

Code Auswählen Erweitern

$a[0] = $sdev;
    $ret = CallFn($sdev, "AttrFn", "set", @a);
    if($ret) {
      push @rets, $ret;
      next;
    }

    my $val = $a[2];
    $val = 1 if(!defined($val));
    $attr{$sdev}{$attrName} = $val;


Du kannst aber mit dem Patch dennoch eine Meldung ausgeben, wenn der Wert einen Fehler haben sollte usw.

Viele Grüße

Markus

[justme1968]

der wert wird eben gerade nicht wieder überschrieben wenn du eine meldung zurück gibst.

Code Auswählen Erweitern

    if($ret) {
      push @rets, $ret;
      next;                <--- überspringt den rest der schleife
    }


gruss
  andre

[Markus Bloch]

Ja gut, aber meiner Meinung ist eine Meldung wie "attribute [xxx] converted to [yyy]" nicht wirklich eine Fehlermeldung. Und momentan bricht die schleife ja nur ab, wenn man eine Fehlermeldung zurückgibt.

Desweiteren sollten (meiner Meinung nach) Modulfunktionen nicht auf die FHEM internen Datenstrukturen direkt zugreifen. Der Zugriff sollte durch entsprechende Funktionen vorgenommen werden, damit so nicht andere Einträge von anderen Modulen/Definitionen verändert werden können.

Gruß
Markus

[justme1968]

es ist eine meldung. von fehler ist nicht die rede.

ich meine ja nur das eine änderung wie du sie vorschlägst auch eine meldung unterstützen sollte.

bei 'meiner' version wird für die geänderten Attribute ja leider auch kein event getriggert.

gruß
  andre

[Markus Bloch]

Dieses Szenario war nun nicht der primäre Anstoss für diesen Patch

Ich würde eine solche informative Meldung im Log ausgeben, da überall in FHEM der gefüllte return-Value eine Fehlermeldung bedeutet.

Evtl. hat Rudi dazu eine Idee. Mir fällt da spontan nichts einfaches ein.

Gruß
Markus

[justme1968]

bei get (und set) ist der gefüllte return wert eine meldung. nicht unbedingt ein fehler.

das attribut setzen würde ich genau so interaktiv sehen wie get und set und eine meldung nur im log werden die meisten nicht sehen.

aber du hast recht. rudi soll erst mal was dazu sagen.

[betateilchen]

Desweiteren sollten (meiner Meinung nach) Modulfunktionen nicht auf die FHEM internen Datenstrukturen direkt zugreifen. Der Zugriff sollte durch entsprechende Funktionen vorgenommen werden

Das ist nicht in allen Fällen umsetzbar.

[Markus Bloch]

Das ist nicht in allen Fällen umsetzbar.

Das ist aktuell auch durchaus so. Daher ja auch Konjunktiv

[betateilchen]

ok, ich korrigiere: Es wird auch künftig vermutlich nicht in allen Fällen umsetzbar sein oder werden.

[rudolfkoenig]

Ich finde es problematisch, wenn ein Programm hinter meinem Ruecken mich korrigiert. Beispiel: ich habe heute eine Weile gebraucht, bis ich kapiert habe, das split(" ", $text) nach \s+ und nicht nach Leerzeichen trennt, ich finde das nicht in Ordnung.

Bei den erwaehnten Szenarien finde ich folgende Loesungen besser:
- Verschluesselung: Das ist kein Attribut, sondern ein set befehl, und das Ergebnis wird in einem Reading gespeichert.
- Syntaxfehler: in dem von AttrFn zurueckgelieferten Fehlermeldung steht, was nach der Ansicht des Moduls richtig waere. Damit lernt der Benutzer, wie man es richtig macht, und wird nicht verwirrt, wenn ein anderes Modul (oder seine Perl-Funktion) damit nicht klarkommt.

Vielleicht gibt es andere Szenarien, wo deine Loesung die Richtige ist, ich sehe diese aber noch nicht.

[Markus Bloch]

Nunja ich erklär mal das Szenario wo diese Idee eigentlich herrührt.

Ich möchte im FB_CALLMONITOR eine Funktion integrieren, die es ermöglicht das Telefonbuch remote via Telnet Zugang ausliest. Dazu ist das FritzBox Passwort notwendig, welches FHEM bekannt sein muss.

Da dieses Passwort für mich am besten als Attribut passt, soll das Passwort beim setzen direkt durch die AttrFn unkenntlich gemacht werden:

mysupersecretpassword => [bXlzdXBlcnNlY3JldHBhc3N3b3JkIA==]

Und so in dieser Form auch in der fhem.cfg gespeichert werden. Die AttrFn erkennt dann, dass der Value in eckigen Klammern ist und weis, dass es sich bereits um ein unkenntliches Passwort handelt.

Das Passwort setzen via Set und das Ergebnis als Reading passt nicht, da es sich meiner Meinung nach nicht um Reading/Event handelt, sondern um einen Konfigurationswert.

Daher würde ich das auf diese Weise gerne lösen.

[justme1968]

das hinterlegen von passwörtern brauchen inzwischen ein paar module und eine allgemeine lösung wäre glaube ich nicht schlecht.

die frage ist was genau das unkenntlich machen bewirken soll. meiner meinung nach sollte das password ist bei einem list nicht sichtbar und man kann die list ausgabe zum debugger direkt posten und weitergeben

das password irgendwie modul spezifisch zu verschlüsseln ohne ein installations spezifisches master password zu haben bringt nichts. jeder der das gleiche modul hat kann das password entschlüsseln.

wie wäre es an der stelle des password einen beliebigen perl ausdruck zuzulassen. dann kann man z.b. einfach {myPassword()} schreiben und das password steht nur in einem 99_myUtils file und taucht bei einem list nirgends auf. noch nicht mal unsicher verschleiert. wenn jemand hier das password direkt als string hin schreibt ist es halt so.

gruss
  andre

[herrmannj]

Hi,

ich finde den Vorschlag von Markus durchaus schlüssig und den Konventionen von fhem angepasst. In Bezug auf Sicherheit hast Du, Andre, sicher recht. Allerdings ist es doch so: wer ein list absetzen kann kommt auch auf die 99er. Die 99er sind für viele user auch eher eine Schranke. Fort know macht jetzt (mMn) weder die eine noch die andere Variante 

vg
jörg