Ungelöst Technischer Nutzer für API
-
In der Anleitung zur API ist erklärt, wie man einen API Key für eine Person erstellen kann. Das ist natürlich schön, wenn man eine eigene Church.Tools App entwickeln möchte, in der sich Personen anmelden können.
Ich möchte jedoch eine Backend-Komponente entwickeln, die mit gewissen Berechtigungen auf die Church Tools API zugreifen soll. Dazu eine Person mit einem kryptischen Namen anzulegen erscheint mir aber eine sehr hässliche Lösung. Schließlich möchte ich keine Gemeindemitglieder durch API Nutzer in der Personenliste verwirren.
Wie kann man einen Nutzer erstellen, dem man über Rollen oder direkt Berechtigungen zuweisen kann und der einen API Key hat, ohne dafür eine Person anlegen zu müssen, bzw. ohne dass der Nutzer in der Personenliste auftaucht?
-
@daniel-lerch du kannst dafür einen Bereich für solche System Nutzer anlegen auf den du keine anderen Benutzer berechtigtst, somit tauchen sie auch in keinen Listen in der Gemeinde auf
-
@jziegeler Wo kann ich System Nutzer anlegen? Finde in der Doku dazu leider nichts
-
@liebsoer Du legst sie so an, wie jeden anderen Benutzer auch. Der "Trick" ist der eigene Bereich, in den du diese Benutzer anschließend packst. Dieser Bereich ist für niemanden sonst sichtbar. Wir haben so einen Bereich "Spezial", in dem unsere ganzen funktionalen IDs stecken (LDAP, Sync, Infos im Gottesdienst). Außerdem ist dort Max Mustermann geparkt (für gemeinde-interne Tutorials).
-
@thommyb Ah okay. Also so, wie ich es auch schon mache. Dachte jetzt, es gibt ne spezielle "Technical User" Section / Modul.
Allgemein fände ich eine separation zwischen echten und technischen Nutzern gut, da diese evtl. andere Felder als normale Nutzer benötigen bzw. die meisten gar nicht. Kann mir gut vorstellen, dass es ein weiterer Tab neben Nutzer und Gruppen.
Wenn das nen interessantes Feature wäre, kann ich mir auch noch in Ruhe Gedanken machen, was meine konkreten Anforderungen sind
-
@liebsoer ich hab an anderer Stelle den Usertype Guest ins Spiel gebracht.
So ein technischer Nutzer könnte auch ein weiter Usertype sein.
Ein extra Modul sehe ich nicht sinnvoll. Aber im Modul „Personen“ gibt es verschiedenen Typen, die dann auch nicht unbedingt gegen die Lizenz zählen.
-
@MichaelG Meinst du damit, einen eigenen Status dafür zu verwenden? Das wäre für mich ebenfalls ein Workaround.
Und wie müsste ich es einstellen, dass die technischen Nutzer bei der Lizenz nicht mitgezählt werden?
Für mich sind "Personen und Gruppen" personenbezogen. Technische Nutzer haben für mich einen völlig anderen Charakter und auch andere Anforderungen und benötigen vieles gar nicht, was für echte Nutzer erforderlich ist.
Für einen technischen Nutzer brauche ich an sich nur einen Nutzernamen, Passwort und die Möglichkeit rechte einzustellen. Evtl. noch Gruppenzugehörigkeit. Alles was unter Adresse und Informationen z.B. ist, benötige ich gar nicht.
Ein weiteres gutes feature wäre die Möglichkeit mehrere Tokens verwenden zu können.Ja, ich kann die Anforderung mit bestehenden Mitteln als Workaround umsetzen. Aus meinem PO & IT Hintergrund empfinde ich die Funktionalität als eigenes Modul in vieler Hinsicht (z.B. aus IT Architektursicht) deutlich schöner
-
@liebsoer das existiert so noch nicht. Mit „ins Spiel gebracht“ meinte ich, als Vorschlag rein gegeben.
Die Idee:
Wenn du einen neuen User erstellst, würdest du einen Usertype auswählen. Optionen z.B.:- Person, 2. Gast/externer Kontakt, 3. Technischer User/Service Account
Je nachdem, was man auswählt, stehen einem unterschiedliche Möglichkeiten zur Verfügung. Für einen Gast kann man z.B. keine pastoralen Felder ausfüllen und keine Berechtigungen vergeben, da ein Gast nur ein Kontakt ist, der nicht auf CT zugreifen kann, aber in Gruppen aufgenommen werden kann, z.B. als Lieferant oder Gast einer KG.
Ein Service Account wäre dann wie von dir beschrieben.
Nur Personen werden gegen die Lizenz gerechnet. Die anderen nicht.
Einen externen Account/Gast sollte aber jederzeit in eine Person umgewandelt werden können und umgekehrt.
Im Endeffekt lehnt sich diese Idee an die Identitäten von M365 an.
Und wie gesagt, das geht noch nicht, sondern wäre ein Feature Request.
