FHEM Forum

Hallo zusammen,

ich habe bereits ein bisschen gesucht und leider kein passenden Beitrag gefunden, daher möchte ich mit diesem Beitrag gerne eine Diskussion starten (oder ein paar Verständnisfragen für mich klären).

Aktuell ist die Situation bei allowed laut https://fhem.de/commandref_DE.html#allowed (https://fhem.de/commandref_DE.html#allowed) wie folgt:

ZitatFalls man mehrere allowed Instanzen definiert hat, die für dasselbe Frontend verantwortlich sind, dann müssen alle Authorisierungen genehmigt sein, um das Befehl ausführen zu können. Auf der anderen Seite reicht es, wenn einer der Authentifizierungen positiv entschieden wird. Die Prüfungen werden in alphabetischer Reihenfolge der Instanznamen ausgeführt.

Nach meinen Verständnis soll allowed eine Art Benutzer/Rechteverwaltung in FHEM darstellen. Bei anderen Anwendungen werden dazu üblicherweise Benutzer mit Authentifizierungen definiert und ihnen anschließend Rechte zugewiesen, ggf. per Gruppen.

Bei allowed ist diese Art der Benutzer/Rechteverwaltung allerdings nicht so einfach möglich: Man kann zwar mehrere allowed für ein FHEMWEB definieren und ihnen Ausführungsrechte per allowedDevices,allowedCommands... zuweisen, in dem Fall müssen aber (wie oben beschrieben) alle allowed die Authorisierung genehmigen, unabhängig von der Authentifizierung (also dem Benutzer). Um verschiedene allowed mit unterschiedlichen Rechten effektiv zu nutzen, müsste man pro allowed ein eigenes FHEMWEB mit eigenem Netzwerkport (& weitere Konfiguration wie SSL, Apache Proxy usw) definieren.

Aus diesem Grund schlage ich vor, die Logik von allowed wie folgt zu ändern:

ZitatFalls man mehrere allowed Instanzen definiert hat, die für dasselbe Frontend verantwortlich sind,  wird zunächst die Authentifizierung entschieden. Das erste allowed, welches die Authentifizierung positiv entscheidet, übernimmt dann alle Authorisierungen, um den Befehl ausführen zu können. Die Prüfungen werden in alphabetischer Reihenfolge der Instanznamen ausgeführt.

Das hieße im Sinne einer Benutzer/Rechteverwaltung, dass allowed eine Gruppe darstellt, welche Benutzer und deren Rechte zusammenführt. Also möglicher Implementierungsansatz könnte das passende allowed einfach an der temporären FHEMWEB-Instanz (à la WEB_127.0.0.1_51650 etc) hinterlegt werden.

Welche Probleme oder technischen Gegebenheiten sprechen gegen dieses Konzept?

Viele Grüße
ManOki

ZitatWelche Probleme oder technischen Gegebenheiten sprechen gegen dieses Konzept?

Dass es meiner Meinung nach ein Hack ist:
- allowed implementiert die beiden Schnittstellen (authenticate und authorize), wenn der Vorschlag implementiert ist, dann _muessen_ andere Implementationen auch immer beide Schnittstellen implementieren.
- die bisherige Logik (mehrere allowed Instanzen sind fuer unterschiedliche Teile zustaendig) funktioniert nicht mehr => Problem bei der Umstellung
- die Loesung (fuer jeden Benutzer eine allowed Instanz zu definieren), ist weder elegant noch effizient.

Es steht jedem frei eine andere Implementierung zu bauen, z.Bsp. gegen Active-Directory/PAM/etc. Falls sich herausstellt, dass irgendetwas direkt vom allowed abhaengt, werde ich das anpassen/entfernen.

Wieso ist es deiner Meinung nach ein Hack? Vllt verstehe ich auch die Idee hinter allowed nicht ganz: wie geschrieben, für mich soll das eine Art Benutzer/Rechteverwaltung sein, ist das richtig so? Ich kann mir irgendwie nicht vorstellen, dass die bestehende Möglichkeit, mehrere allowed-Instanzen zu verwenden, tatsächlich 'produktiv' eingesetzt wird. Was ist der angedachte Anwendungsfall dazu?

Zitat von: rudolfkoenig am 06 September 2018, 11:55:44
- allowed implementiert die beiden Schnittstellen (authenticate und authorize), wenn der Vorschlag implementiert ist, dann _muessen_ andere Implementationen auch immer beide Schnittstellen implementieren.

Inwiefern müssen andere Implementationen beide Schnittstellen implementieren? Aktuell brauche ich keinerlei authorize Informationen hinterlegen, sondern nur authenticate und kann mich normal anmelden und hab volle Rechte (quasi Administrator). Wenn ich dann ein zweites allowed anlege, z.B. Gast-Account, dann schränke ich dort nebst authenticate auch authorize ein. Meiner Meinung nach ist für ein authorize immer ein authenicate notwendig. Ausnahme wäre der Fall, wenn ich FHEMWEB sowieso nur als Gast-Account ansehe und den Rest selbst per Config-File einrichte oder eben ständig die allowed-Konfiguration zu diesem Zweck ändere (FHEM stoppen, FHEMWEB auf localhost stellen, allowed auf "Admin-Modus", FHEM starten, kleine Änderung machen, FHEM stoppen, FHEMWEB wieder auf global, allowed auf "Gast-Modus", FHEM starten).

Zitat von: rudolfkoenig am 06 September 2018, 11:55:44
- die bisherige Logik (mehrere allowed Instanzen sind fuer unterschiedliche Teile zustaendig) funktioniert nicht mehr => Problem bei der Umstellung

Ok, das würde sich zwecks Abwärtskompatibilität umgehen lassen, indem ein weiteres Modul hinzugefügt wird, anstatt die allowed-Logik zu ersetzen.

Zitat von: rudolfkoenig am 06 September 2018, 11:55:44
- die Loesung (fuer jeden Benutzer eine allowed Instanz zu definieren), ist weder elegant noch effizient.

Es müsste nicht pro Benutzer ein eigenes allowed definiert werden, sondern nur pro Rechte-Set (aka Gruppe). Siehe https://forum.fhem.de/index.php?topic=12043.0 (https://forum.fhem.de/index.php?topic=12043.0). Ich habe bereits jetzt eine Konfiguration, wo ich mehrere User habe, teils mit verschiedenen Passwörtern für unterschiedliche Geräte. Falls also mal eins abhanden kommen würde, müsste ich nicht alle Authentifizierungsinformationen austauschen. Die Konfiguration habe ich mal unten angehangen.

Zitat von: rudolfkoenig am 06 September 2018, 11:55:44
Es steht jedem frei eine andere Implementierung zu bauen, z.Bsp. gegen Active-Directory/PAM/etc. Falls sich herausstellt, dass irgendetwas direkt vom allowed abhaengt, werde ich das anpassen/entfernen.

Bevor ich anfange, etwas zu entwickeln, möchte ich erstmal den aktuellen Stand verstehen und herausfinden, ob es nicht anderweitige Möglichkeiten/Konfigurationen gibt.


Mein aktuelles allowed_WEB:
Internals:
   CFGFN     
   NAME       allowed_WEB
   NR         3
   STATE      validFor:WEB
   TYPE       allowed
   validFor   WEB
   READINGS:
     2018-09-06 11:36:49   state           validFor:WEB
   helper:
     bm:
       allowed_Attr:
         cnt        1
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        06.09. 11:55:04
         max        2.00271606445312e-05
         tot        2.00271606445312e-05
         mAr:
           set
           allowed_WEB
           userattr
           cost salt logins admin myuser Handy Tablet1 Tablet2 sysmon1
       allowed_Authenticate:
         cnt        6475
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        06.09. 11:41:06
         max        0.266385078430176
         tot        13.5465526580811
         mAr:
           HASH(0x55a0b0c6e050)
           HASH(0x55a0b5c4aca0)
           HASH(0x55a0b0608378)
       allowed_Authorize:
         cnt        6497
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        06.09. 11:43:38
         max        0.000108003616333008
         tot        0.0608229637145996
         mAr:
           HASH(0x55a0b0c6e050)
           HASH(0x55a0b603e580)
           cmd
           perl
       allowed_Set:
         cnt        4
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        06.09. 11:53:43
         max        5.10215759277344e-05
         tot        0.000105142593383789
         mAr:
           HASH(0x55a0b0c6e050)
           allowed_WEB
           ?
Attributes:
   Tablet1     myuser:7782d16abc8d10fxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   Tablet2     myuser:7bae488994675a4xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   myuser      myuser:3b228dbe6cc4a47xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   admin       admin:a470eb567716203xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   basicAuth  {   use Digest;    my $SELF = "allowed_WEB";    my $cost = AttrVal($SELF, "cost", 1);   my $salt = AttrVal($SELF, "salt", "-");   my $logins = AttrVal($SELF, "logins", "");    my $bcrypt = Digest->new('Bcrypt');   $bcrypt->cost($cost);   $bcrypt->salt($salt);   $bcrypt->add($password);   my $hash = $bcrypt->hexdigest;    my $auth = "$user:$hash";    foreach (split / /, $logins) {     if ($auth eq AttrVal($SELF, $_, "")) {       return 1;     }   }   return 0; }
   cost       12
   sysmon1    sysmon1:9352ad0c074876fxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   logins     admin myuser Handy Tablet1 Tablet2 sysmon1
   Handy      myuser:302c9e10b21a9854xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   room       hidden
   salt       abcdefgh♥stuff
   userattr   cost salt logins admin myuser Handy Tablet1 Tablet2 sysmon1
   validFor   WEB

Und der formatierte basicAuth-Code, da Leerzeichen nicht gespeichert werden:
{
  use Digest;

  my $SELF = "allowed_WEB";
  my $cost = AttrVal($SELF, "cost", 1);
  my $salt = AttrVal($SELF, "salt", "-");
  my $logins = AttrVal($SELF, "logins", "");

  my $bcrypt = Digest->new('Bcrypt');
  $bcrypt->cost($cost);
  $bcrypt->salt($salt);
  $bcrypt->add($password);

  my $hash = $bcrypt->hexdigest;
  my $auth = "$user:$hash";

  foreach (split / /, $logins) {
    if ($auth eq AttrVal($SELF, $_, "")) {
      return 1;
    }
  }
  return 0;
}

Der Ansatz von allowed ist, dass man eine separate FHEMWEB/telnet/MQTT2_SERVER Instanz hat fuer jeden Benutzerkreis, diesen kann man mit mehreren allowed Instanzen einschraenken. Ich will nicht behaupten, dass das in jeder Situation optimal ist, will aber auch nicht ohne Grund daran aendern.

ZitatMeiner Meinung nach ist für ein authorize immer ein authenicate notwendig.

Gegenbeispiel ist ein Bildschirm an der Wand, ohne Zugangskontrolle, und nur fuer die Bedienung eines Zimmers zustaendig.

ZitatIch kann mir irgendwie nicht vorstellen, dass die bestehende Möglichkeit, mehrere allowed-Instanzen zu verwenden, tatsächlich 'produktiv' eingesetzt wird.

Vorstellen kann man schon was, auch wenn man es einfacher mit gleichem Ergebnis loesen koennte. Leider halten sich  kaum Benutzer an das, was ich mit einem Modul ermoeglichen wollte, es wird so ziemlich alles ausprobiert, was den Server nicht zum Absturz bringt. Ich befuerchte Support-Aufwand beim Aendern, und das Ergebnis der Aenderung waere immer noch nicht ideal. Ich hoffe, dass durch mein "ich-stell-mich-quer" neben allowed eine Alternative zu allowed mit gutem Multiuser-Support entsteht.:)

Ok, mit der Antwort ich verstehe besser, wozu allowed gedacht ist und wozu eher nicht.

Zitat von: rudolfkoenig am 06 September 2018, 14:07:42
Gegenbeispiel ist ein Bildschirm an der Wand, ohne Zugangskontrolle, und nur fuer die Bedienung eines Zimmers zustaendig.

In dem Fall würde ich einen "Benutzer"-Account z.B. 'Wohnzimmer' erstellen und dem dann die entsprechenden Rechte zuweisen. Das Gerät (also der PC-Teil vom Bildschirm) müsste dann eben die Login-Daten dauerhaft gespeichert haben und sich beim Starten automatisch anmelden. Es müsste sich also als 'Wohnzimmer' authentifizieren, bevor es mit dem Rechte-Set fürs Wohnzimmer authorisiert wird. Gegenbeispiel zum Gegenbeispiel: Das Zimmer ist in einer WG ;) Dann sollte die aktuelle Person ja nicht Zugriff auf das verschlossene Zimmer nebenan haben, nur weil der Bildschirm sich eben nicht authentifiziert hat und deswegen volle Authorisierung für alle Zimmer bekommen müsste. (Die Lösung mit mehreren FHEMWEB/allowed schließe ich hier ganz bewusst aus.)

Aber zurück zum Thema: Du wirst demnach keine Weiterentwicklung in diese Richtung vornehmen, weder an allowed, noch einem anderen/neuen Modul? Gibt es eine technische Beschreibung von allowed? Leider bin ich nicht sehr fit im Perl-Programmieren :-X Ich schaue schon für 3 Zeilen mit einer Schleife 20 min im Internet...

Zitat von: ManOki am 06 September 2018, 14:44:51
Ok, mit der Antwort ich verstehe besser, wozu allowed gedacht ist und wozu eher nicht.

In dem Fall würde ich einen "Benutzer"-Account z.B. 'Wohnzimmer' erstellen und dem dann die entsprechenden Rechte zuweisen. Das Gerät (also der PC-Teil vom Bildschirm) müsste dann eben die Login-Daten dauerhaft gespeichert haben und sich beim Starten automatisch anmelden. Es müsste sich also als 'Wohnzimmer' authentifizieren, bevor es mit dem Rechte-Set fürs Wohnzimmer authorisiert wird. Gegenbeispiel zum Gegenbeispiel: Das Zimmer ist in einer WG ;) Dann sollte die aktuelle Person ja nicht Zugriff auf das verschlossene Zimmer nebenan haben, nur weil der Bildschirm sich eben nicht authentifiziert hat und deswegen volle Authorisierung für alle Zimmer bekommen müsste. (Die Lösung mit mehreren FHEMWEB/allowed schließe ich hier ganz bewusst aus.)

Aber zurück zum Thema: Du wirst demnach keine Weiterentwicklung in diese Richtung vornehmen, weder an allowed, noch einem anderen/neuen Modul? Gibt es eine technische Beschreibung von allowed? Leider bin ich nicht sehr fit im Perl-Programmieren :-X Ich schaue schon für 3 Zeilen mit einer Schleife 20 min im Internet...

Genau so habe ich 2015 auch angefangen. Ich brauchte etwas ganz dringend und es gab keine vernünftige Lösung. Also habe ich mich hingesetzt und gelernt.
Glaube mir, es ist leichter wie es aus schaut.

ZitatDu wirst demnach keine Weiterentwicklung in diese Richtung vornehmen, weder an allowed, noch einem anderen/neuen Modul?

Sag niemals nie, aber ich habe z.Zt. nicht das Problem/Beduerfnis.

ZitatGibt es eine technische Beschreibung von allowed?

Mir ist nichts bekannt. Kurz:

- fuer das Authenticate Interface muss man ein AuthenticateFn implementieren, was mit dem eigenen hash, mit dem client hash und ein Parametr aufgerufen wird. Der Parameter ist im Falle von FHEMWEB die HTTP-Headerdaten, beim telnet das Passwort selbst, und sonst "basicAuth:".base64("user:password"). Sie liefert 0 zurueck, falls sie sich nicht zustaendig fuehlt, 1 falls ok, und 2 falls nicht ok.

- fuer das Authorize Interface muss man ein AuthorizeFn implementieren, was mit dem eigenen hash, mit dem client hash und mit einem Typ und einem Parameter aufgerufen wird. Fuer Typ "cmd" ist das Argument perl, shell oder ein FHEM-Befehl, fuer Typ "devicename" der Name einer FHEM-Instanz. Sie liefert 0 zurueck, falls sie sich nicht zustaendig fuehlt, 1 falls ok, und 2 falls nicht ok (wie AuthenticateFn).

Ich lese mal mit, falls es noch zu spannenden Entwicklungen kommt  8)
Gedanklich bin ich ja eh bei einem allowedex-Modul, gehört nur noch fertig entwickelt......

LG Thomas

Hallo Thomas,

wofür steht "allowedex-Modul"? allowed extension? Welche Gedanken hast du dir bereits dazu gemacht? Hast du neben deinen Gedanken vllt sogar schon erste Schritte (Code oder anderes) gemacht?

Viele Grüße
ManOki

Zitat von: ManOki am 06 September 2018, 17:10:52
Hallo Thomas,

wofür steht "allowedex-Modul"? allowed extension? Welche Gedanken hast du dir bereits dazu gemacht? Hast du neben deinen Gedanken vllt sogar schon erste Schritte (Code oder anderes) gemacht?

Viele Grüße
ManOki

allowedex = allowed extended

Mehrere allowedex-Geräte für eine FHEMWEB-Instanz.
Authentifizierung durch das erste "passende" allowedex Gerät, über das dann auch die Autorisierung der Kommandos etc. passiert.
Ein Match kann über eine passende User/PW Kombination oder eine IP Adresse passieren, damit wären auch Tablets an der Wand etc. abgefangen.

Code gibts noch keinen, ich muss mich zuvor noch genauer in das bestehende allowed einlesen.
Ob ich das dann hinbekomme ist auch fraglich  ???

LG Thomas

Authentifizierung per IP: Ok, von einem gewissen Punkt auch nicht viel unsicherer als die Variante, die Zugangsdaten fest im Gerät zu hinterlegen. Ich persönlich würde das nie machen, aber es mag sicher für den ein oder anderen ein akzeptabler Weg sein.

Also bisher haben wir folgende Anforderungen/Ideen/Wünsche:

Authentifizierung (pro allowedex-Instanz)

• lokal per Username/PW (in Fhem gespeichert), eventuell mit App-Pins vergleichbar zu nextcloud (also ein weiteres PW für den gleichen Benutzernamen, dass z.B. bei Verlust als ungültig markiert werden kann, ohne den gesamten Account zu sperren, überall alle PW zu ändern)
• per PAM
• per LDAP
• per IP (mit separat zuweisbaren Benutzernamen, falls sich die IP mal ändert)

Authorisierung
Hier stellen sich mir einige Fragen/Design-Entscheidungen/Anforderungen:

Allgmein:

• Benutzer sollten Gruppen zugeordnet werden können (n:m)
• Gruppen können Zugriffsrechte zugewiesen werden (n:m)
• Benutzer können Zugriffsrechte zugewiesen werden?? Wäre ein nice-to-have, aber letztlich geht es auch ohne, indem eine Gruppe für einen einzelnen Benutzer erstellt wird
• Sollte der aktuelle Benutzer und dessen Gruppen durch andere Module abgefragt werden können? z.B. bei DOIF, um entsprechend andere Aktionen durchzuführen? (Ich vermute, hierfür ist ein tiefgreifender Umbau von FHEM erforderlich, da die Informationen bei Events entsprechend durchgereicht werden müssten)

Wo werden die Zugriffsrechte gespeichert?

• vergleichbar zu allowed: allowedCommands (set, attr, get...) und allowedDevices: devspec an der allowedex-Instanz
• vergleichbar zu DbLog: globale Attribute (wie DbLogInclude/DbLogExclude) an jedem einzelnen Device
• zu 1. und 2.: sollte pro Gruppe ein eigenes Attribut verwendet werden oder lieber lange Definitionen in einem einzelnen Attribut?
• für jede Gruppe eine eigene Modul-Instanz mit den Zugriffsrechten
• Wo soll die Zuordnung Benutzer->Gruppen hinterlegt sein?

Wie und welche Zugriffsrechte werden gespeichert?

• Was sollte das default-Recht sein, wenn nichts explizit festgelegt wurde: alles erlauben oder alles verbieten? Sollte diese Einstellung konfigurierbar sein?
• Sollte man explizit Allow und Deny parallel definieren können? Welche Rechtezuweisung gewinnt? Sollte diese Einstellung konfigurierbar sein?
• vergleichbar zu allowed: allowedCommands und allowedDevices ohne Kombination, also für alle x Devices -> alle y Rechte
• pro device/devspec eigene Rechte, also z.B. device1:set,device2:set,get
• weitere Einschränkungen der Commands, also z.B. welche set-commands und deren Parameter: set device1 volume * (aber eben nicht set device1 powermode shutdown)
• Sollte es ein spezielles Recht "Rechtezuweisung ändern" geben? Bsp: werden Zugriffsrechte an globalen Attributen der einzelnen devices gespeichert, wird es ggf. sehr aufwendig, das Ändern der Rechte zentral zu erlauben oder zu verbieten, da alle devices angepackt werden müssten. Andererseits kann damit ermöglicht werden, dass Benutzer (keine Admins) anderen Benutzern Rechte zuweisen können
• Weitere Rechte wie das Anzeigen/Ausblenden von (einzelnen) Attributen, Readings oder Internals? Ggf. relevant, um die Rechte anderer Benutzer zu verstecken oder damit GUIs nur noch relevante/erlaubte Optionen anzeigen (Zu beachten wäre, dass GUIs wie Tablet-UI oder andFHEM vermutlich weiterhin Zugriff auf den TYPE oä. haben müssen, um speziellere Darstellungen (z.B. für Thermostate und deren Zuordnung zu Fensterkontakten) anbieten zu können)
• Weitere Rechte wie das Anzeigen/Ausblenden von Räumen/Gruppen oder anderen GUI-Elementen? Also sollte man einen Raum "mein geheimer keller" sehen, auch wenn dieser leer ist, weil man keine Zugriffsrechte auf die Devices darin hat?

Das sind alles keine Festlegungen, sondern sollen eine Diskussionsgrundlage bieten. Wer weitere Ideen/Anforderungen hat, gerne her damit! Wer eine Meinung zu dem Thema hat, ebenso gerne her damit! Ihr könnt auch gerne euer Szenario/Anwendung von fhem erläutern und welche Möglichkeiten ihr euch wünscht, Benutzer-/Rechteverwaltung vorzunehmen (sowas wie Gast-Account, Tablet an der Wand für die Steuerung von einem einzelnen Zimmer).

Gibt es bereits Ansätze/Versuche/Beiträge/Implementierungen (außer allowed), die sich mit dem Thema Benutzer-/Rechteverwaltung in FHEM beschäftigt haben?

Noch eine allgemeine Frage: Kann bei der devspec-Notation :FILTER=NAME=WERT der NAME Internal, Reading und Attribute sein? Dann könnte per devspec sehr leicht auf rooms, groups oder ähnlichen eingeschränkt werden.

@rudolfkoenig: Danke schonmal für die Infos zu AuthenticateFn und AuthorizeFn! Eine Frage an dich: Mit konfiguriertem allowed (attr erlaubt, set verboten) setze ich ein Attribut. Daraufhin triggert ein notify/DOIF und führt einen set-Command aus. Wird das notify/DOIF ebenfalls mit dem Rechte-Set vom allowed ausgeführt (also die Durchführung vom set-Command verboten) oder hat das keinen Einfluss?

Zitatwelche set-commands und deren Parameter: set device1 volume * (aber eben nicht set device1 powermode shutdown)

Die Befehlsparameter werden z.Zt. nicht an AuthorizerFn weitergereicht.

ZitatGibt es bereits Ansätze/Versuche/Beiträge/Implementierungen (außer allowed), die sich mit dem Thema Benutzer-/Rechteverwaltung in FHEM beschäftigt haben?

Die Authorize/Authenticate Schnittstelle ist aus den telnet password bzw. FHEMWEB basicAuth Attribut entstanden, damit Entwickler nicht nur Patches fuer telnet oder FHEMWEB beitragen, sondern eigene Authenticate/Autorize Module bauen. Bisher ohne Erfolg.

ZitatWird das notify/DOIF ebenfalls mit dem Rechte-Set vom allowed ausgeführt

Die Authorisierung/Authentifizierung haengt an dem "Eingangsinterface" ($cl, eine Instanz von FHEMWEB, telnet, etc), ein notify hat diese Daten nicht mehr zur Verfuegung, da Events diese Information nicht weiterreichen.
Anders ausgedrueckt: Die Authorisierung findet in AnalyzeCommand und devspec2array statt, und wenn diese ohne $cl aufgerufen werden, dann kann auch keine Pruefung stattfinden. Wenn wir $cl auch bei den Events weiterreichen wuerden, dann koennte man eine Authorisierung von anderen Eingangsquellen wie ZWave-Fernbedienung, etc realisieren. Ich bin aber z.Zt. nicht ueberzeugt, dass es mir den Umbau Wert ist, und ich wuesste auch kein Szenario, wo das notwendig ist.

ZitatNoch eine allgemeine Frage: Kann bei der devspec-Notation :FILTER=NAME=WERT der NAME Internal, Reading und Attribute sein? Dann könnte per devspec sehr leicht auf rooms, groups oder ähnlichen eingeschränkt werden.

Ja, siehe https://fhem.de/commandref_modular.html#devspec

Einen Versuch LDAP mit ins Spiel zubringen gab es hier (https://forum.fhem.de/index.php/topic,77448). Viel Interesse scheint es an dem Theama aber auch nicht zugeben: 5 Downloads in den letzten 11 Monaten...

Hi Rudi,

hast du ggf. noch vor ein allowedDevicesDevspec hinzuzufügen?
Dann könnte man bspw. auf einen Raum einschränken.

VG, Markus

Zitathast du ggf. noch vor ein allowedDevicesDevspec hinzuzufügen?

So gefragt: nein, habe ich eigentlich nicht.
Kann aber darueber nachdenken, wenn grosses Interesse da ist.

Als Workaround kann man allowedDevicesRegexp verwenden.

Per allowedDevicesRegexp müsste ich die Geräte eines Raumes via Namen filtern, richtig? Oder gibt es da noch eine andere Möglichkeit die ich nicht sehe?

ZitatPer allowedDevicesRegexp müsste ich die Geräte eines Raumes via Namen filtern, richtig?

Ja.

Hallo,

ich hätte noch immer Interesse an allowedDevicesRegexp, da es m.E. eleganter und weniger Fehler-anfällig ist, als hier reguläre Ausdrücke zu nutzen.

Wie sieht das Interesse aus?