(FHEM) Internes: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
(Die Seite wurde neu angelegt: „Das Programm ist wie folgt aufgebaut.“) |
|||
| Zeile 1: | Zeile 1: | ||
| − | Das | + | =FUUID= |
| + | Functional Universally Unique IDentifier | ||
| + | |||
| + | |||
| + | Die FUUID ist ein INTERNAL, also etwas, was FHEM intern (bzw. einige Module) benötigen um dem User bessere Funktionalität zur Verfügung zu stellen. Der User soll damit nichts zu tun haben (müssen) | ||
| + | |||
| + | [https://forum.fhem.de/index.php/topic,121468.0/all.html Heftigst diskutiert]: | ||
| + | <pre> | ||
| + | Otto123 ist hier: https://forum.fhem.de/index.php/topic,94494.msg1160727.html#msg1160727 aufgefallen, dass die von FHEM generierte UUID zu lang ist. Ich will es jetzt korrigieren, und um 4 Stellen (2 Bytes) verkuerzen. Es geht nur um das Generieren, alte UUIDs werden nicht angefasst. | ||
| + | </pre> | ||
| + | <pre> | ||
| + | Hallo Jungs, | ||
| + | |||
| + | ich habe eigentlich gar kein Problem mit der Länge der UUID. Ich hatte mir (mangels Kenntnis) eine UUID einfach im System geholt (cat /proc/sys/kernel/random/uuid). | ||
| + | Gestern dachte ich, ich kann doch auch einfach die von FHEM nehmen und hab mir die Frage gestellt: Ist eine UUID immer eine UUID ? (also mit gewissem Aufbau) oder ist das einfach eine große (je größer je besser) Zufallszahl? | ||
| + | Die Dinger untereinander kopiert und da fiel es auf :-\ | ||
| + | Kurz gesucht und gefunden: es gibt eine Festlegung für die UUID / GUID : 128 bit, Algorithmus, 32 Zeichen in definierten Gruppen plus 4 Bindestriche = 36 Zeichen gesamte Länge usw. | ||
| + | Ich dachte: hier ist in der FHEM Implementierung ev. ein Fehler passiert. | ||
| + | |||
| + | Es ist immer gut sich an Standards zu halten. ;) und an Fehlern muss man nicht zwingend festhalten. Ich will damit nicht sagen es ist ein Fehler passiert - aber die FUUID entspricht nicht dem gängigen Standard. | ||
| + | Jetzt wäre noch zu klären: Nimmt FHEM Typ 3 oder Typ 4 ? (ich duck mich) :D | ||
| + | |||
| + | Gruß Otto | ||
| + | </pre> | ||
| + | |||
| + | <pre> | ||
| + | RFC4122 referenziert klar die Versionen 1-5. Je nach Version der UUID wird Einzigartigkeit in "Space und Time" angestrebt. Das involviert (je nach Version) die MAC Adresse sowie Clock im 100ns Slots. Damit Clock auch bei Zeit- Anpassungen (NTP / Sommer- Winterzeit) funktioniert gibt es eine Clock Sequence. Daher ist der Verweis auf RFC4122 in etwa genauso qualifiziert wie ein möglicher Verweis auf die 16bit Bluetooth UUID. Da steht auch UUID dran, das kann man nicht leugnen und das ist ebenfalls ein Standard. Lass uns doch den nehmen | ||
| + | </pre> | ||
| + | =csrfToken= | ||
| + | Cross Site Request Forgery[https://www.ionos.de/digitalguide/server/sicherheit/was-ist-cross-site-request-forgery/] | ||
| + | csrfToken schützt dich davor, dass dir jemand anderes einen FHEM-Befehl unterjubelt, der das nicht können dürfen soll. Du hast es aber vermutlich nicht so verstanden, aber csrfToken hat eine große Sicherheitsschwachstelle (jemand könnte z.B. hier ein "Bild" einfügen, dessen automatischer Aufruf durch den Browser bei dir zu Hause irgendeine Aktion auslöst) in FHEMWEB behoben und wenn du diese mit none aushebelst, stellst du diesen unsicheren Zustand wieder her. (Informations-)Sicherheit ist meistens nicht so komfortabel wie Unsicherheit, aber - in Anlehnung an einen bedeutenden Denker des 18. Jahrhunderts: Wer Sicherheit für Komfort aufgibt, hat bald weder noch. | ||
Version vom 10. August 2022, 15:25 Uhr
FUUID
Functional Universally Unique IDentifier
Die FUUID ist ein INTERNAL, also etwas, was FHEM intern (bzw. einige Module) benötigen um dem User bessere Funktionalität zur Verfügung zu stellen. Der User soll damit nichts zu tun haben (müssen)
Otto123 ist hier: https://forum.fhem.de/index.php/topic,94494.msg1160727.html#msg1160727 aufgefallen, dass die von FHEM generierte UUID zu lang ist. Ich will es jetzt korrigieren, und um 4 Stellen (2 Bytes) verkuerzen. Es geht nur um das Generieren, alte UUIDs werden nicht angefasst.
Hallo Jungs, ich habe eigentlich gar kein Problem mit der Länge der UUID. Ich hatte mir (mangels Kenntnis) eine UUID einfach im System geholt (cat /proc/sys/kernel/random/uuid). Gestern dachte ich, ich kann doch auch einfach die von FHEM nehmen und hab mir die Frage gestellt: Ist eine UUID immer eine UUID ? (also mit gewissem Aufbau) oder ist das einfach eine große (je größer je besser) Zufallszahl? Die Dinger untereinander kopiert und da fiel es auf :-\ Kurz gesucht und gefunden: es gibt eine Festlegung für die UUID / GUID : 128 bit, Algorithmus, 32 Zeichen in definierten Gruppen plus 4 Bindestriche = 36 Zeichen gesamte Länge usw. Ich dachte: hier ist in der FHEM Implementierung ev. ein Fehler passiert. Es ist immer gut sich an Standards zu halten. ;) und an Fehlern muss man nicht zwingend festhalten. Ich will damit nicht sagen es ist ein Fehler passiert - aber die FUUID entspricht nicht dem gängigen Standard. Jetzt wäre noch zu klären: Nimmt FHEM Typ 3 oder Typ 4 ? (ich duck mich) :D Gruß Otto
RFC4122 referenziert klar die Versionen 1-5. Je nach Version der UUID wird Einzigartigkeit in "Space und Time" angestrebt. Das involviert (je nach Version) die MAC Adresse sowie Clock im 100ns Slots. Damit Clock auch bei Zeit- Anpassungen (NTP / Sommer- Winterzeit) funktioniert gibt es eine Clock Sequence. Daher ist der Verweis auf RFC4122 in etwa genauso qualifiziert wie ein möglicher Verweis auf die 16bit Bluetooth UUID. Da steht auch UUID dran, das kann man nicht leugnen und das ist ebenfalls ein Standard. Lass uns doch den nehmen
csrfToken
Cross Site Request Forgery[1]
csrfToken schützt dich davor, dass dir jemand anderes einen FHEM-Befehl unterjubelt, der das nicht können dürfen soll. Du hast es aber vermutlich nicht so verstanden, aber csrfToken hat eine große Sicherheitsschwachstelle (jemand könnte z.B. hier ein "Bild" einfügen, dessen automatischer Aufruf durch den Browser bei dir zu Hause irgendeine Aktion auslöst) in FHEMWEB behoben und wenn du diese mit none aushebelst, stellst du diesen unsicheren Zustand wieder her. (Informations-)Sicherheit ist meistens nicht so komfortabel wie Unsicherheit, aber - in Anlehnung an einen bedeutenden Denker des 18. Jahrhunderts: Wer Sicherheit für Komfort aufgibt, hat bald weder noch.
