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

Begonnen von Markus Bloch, 12 Dezember 2014, 22:09:36

Vorheriges Thema - Nächstes Thema

hexenmeister

Hm... Leider. Etwas Isolation der Module wäre schön nicht schlecht. Mit der Verbreitung steigt auch Gefahr, dass jemand auf diesem Wege, also durch Manipulation eines Moduls, in das System einbricht. Ist aber wirklich ein anderes Thema.

justme1968

ja. dafür bräuchte man etwas in richtung des sanbox vorschlags . aber das ist wirklich ein ganz anderes thema.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

tupol

Zitat von: justme1968 am 29 Dezember 2014, 20:01:27
das ist nicht wirklich eine gute idee. dann funktioniert rename nicht mehr.

wir reden nicht von einem hoch sicherheits system. wenn du anderen modulen nicht traust hash du ein ganz anderes problem.

Das hat nichts mit trauen zu tun sondern mit vorhersehbaren Fehlern. Ich melde mich auch gerne als typischer Kandidat. ;)

Module (z.B. FRITZBOX) werden zudem auch mehrfach verwendet und brauchen jedes ein eigenes Login. Zudem wäre es damit auch möglich, die Passwortdatei zu komprimieren, indem alle Passwörter entfernt werden, deren Device-Namen nicht mehr vorhanden sind. "Rename" muss natürlich im Modul berücksichtigt werden, aber dafür gibt es ja schon eine Funktion. Die könnte man dann auch gleich durch eine Rename-Funktion in dem Framework unterstützen.

justme1968

ob die beziehung zwischen modul und password 1:n, n:1 oder n:m ist hängt aber vom modul selber ab. hier was vorzuschreiben ist unter umständen falsch. oder man sollte gleich konsequent sein und $hash verwenden und es im rename und delete (und copy?) gleich mit berücksichtigen.

es kommt halt immer mehr dazu und aus einer einfachen möglichkeit ein password zu verschleiern/verbergen wird etwas das so kompliziert ist das es nicht mehr umgesetzt wird.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

tupol

Ich finde das nicht kompliziert sondern nur konsequent im Sinn des modularen Aufbaus von FHEM. Hier jetzt von diesem Modul-Konzept abzuweichen, finde ich nicht gut. Man sollte die Möglichkeit von crossover-Fehlern so gering wie nur möglich halten. Letztendlich handelt es sich hier nur um Attributwerte, die "geschützt" ausgelagert werden und nicht mehr in der cfg stehen.