Konfigurationen alle in der Datenbank?

[Marvin G. - FZJ]

Hallo,


ich wollte mich mal erkundigen, ob in KIX18 jetzt alle Konfigurationen in der Datenbank sind? In KIX 17 war es so, dass z.B. die AD-Anbindung direkt über eine Daten mitgegeben werden konnte. Und Einstellungen wurden in der ZZZAuto gespeichert, sodass man theoretisch diese Datei in ein anderes System spielen konnte und dann alle Einstellungen hatte.


Hintergrund der Frage ist, dass wir zwecks Automatisierung das System direkt mit Grundkonfigurationen bereitstellen wollen würden, wie z.B. die AD-Anbindung. Geht das? Könnte ich z.B. auch gezielt Einstellungen aus der Sysconfig sichern, die ich bei der Bereitstellung einfach wieder einspielen kann?


Viele Grüße
Marvin

[Torsten Thau]

Hi Marvin,

die Konfiguration liegt direkt in der DB. Export und Import von Einstellungen kann über die REST-API erfolgen.

Im Falle der Authentifizierung GET {{ host  }}/{{ webapi  }}Authentication%23%23%23000-Default (URL-encoded SysConfig-Schlüssel "Authentication###000-Default") - oder eben ein PATCH auf obige URL mit der jeweiligen Konfiguration mit passendem JSON-Body (hier nur DB-Auth):

Code Auswählen Erweitern


{
  "SysConfigOption": {
    "Value": [
        {
          "Config": {
            "CryptType": "sha2"
          },
          "Enabled": 1,
          "Module": "Kernel::System::Auth::DB",
          "Name": "Local Database"
        }
      ]
    }
}


VG, Torsten

[Marvin G. - FZJ]

Hallo Thorsten,


danke für die Antwort.


Ich versuche das gerade einmal zu testen mit Hilfe von "Insomnia". Einen Token kann ich mir per POST schon mal holen. Leider bekomme ich mit diesem TOKEN aber kein PATCH hin. Die Doku hierzu habe ich mir angeschaut, leider sind dort keine wirklichen Beispiele drin, weshalb mir das nicht wirklich weiter hilft.


Wenn ich den Header "Authorization" mit dem vorher ausgelesenen Token mitgebe, bekomme ich die Antwort:

Code Auswählen Erweitern


{
  "Code": "Authorization.NoToken",
  "Message": "No token in \"Authorization\" header found. "
}


Gibt es noch etwas, was ich hier mitgeben muss? Habe auch schon "Token: ..." versucht oder einen Zusätzlichen Header "Token".


Viele Grüße
Marvin

[Torsten Thau]

Hi Marvin,


Du bist schon nahe dran. Es scheint nur ein Doppelpunkt (hinter Token) zuviel zu sein- so sollte es mit dem Header klappen:

Code Auswählen Erweitern


Authorization: Token eyJhb...thatshouldbeyourtokenvalue...uv9sFAmU


CU, Torsten

[Marvin G. - FZJ]

Hallo Torsten,


ah, so knapp :)


Hat funktioniert, vielen dank.


Viele Grüße
Marvin

[Marvin G. - FZJ]

Hallo Torsten,


jetzt kommt gleich die nächste Frage:
Ich will nun ein json übermitteln. Dort drin ist folgender Part:

Code Auswählen Erweitern


"ContactUserSync": {
    "Email": "mail",
    "Firstname": "givenname",
    "Lastname": "sn",
    "Phone": "telephoneNumber",
    "PrimaryOrganisationID": "department",
    "UserLogin": "sAMAccountName",
    "IsAgent": "SET:1"
},


Die Antwort ist

Code Auswählen Erweitern


{
  "Message": "Validation of attribute Email failed (mail)!",
  "Code": "Validator.Failed"
}


Das gleiche habe ich auch, wenn ich

Code Auswählen Erweitern


"Config": {
    "Charset": "utf-8",
},


drin habe. Dort meckert er halt das "utf-8" an. Wenn ich die beiden Einträge raus lösche, ist alles in Ordnung. Ich kann auch im Falle der Mail folgendes machen:

Code Auswählen Erweitern


"Email": "(mail)",

Dann funktioniert das Setzen des Schlüssels zwar, aber mit den Klammern funktioniert der sync ausm AD dann aber nicht.


Wenn ich die Config im Webinterface einsetze, funktioniert das so wie ich das brauche (also mit "Email": "mail").


Wenn ich mir über http://{fqdn}:{port}/api/v1/system/config/Authentication%23%23%23000-Default den Default-Wert auslese (also vor manueller Anpassung) und dann versuche diesen als als json-File über die webapi zu setzen, kommt das gleiche. Er mag also scheinbar Charset und Email nicht.


Mache ich wieder was falsch oder gibt es hier vielleicht ein Problem?


Viele Grüße
Marvin


Edit:
Ich hab gerade zufällig gefunden, was mich hindert:

Code Auswählen Erweitern

API::Validator::Module###EmailAddressValidator
Mache ich das aus, kann ich auch "mail" eintragen. Hätte das denn noch andere Auswirkungen auf das System?

[Torsten Thau]

Hallo,


Danke für die Rückmeldung. In der Tat habe ich das Szenario so noch nicht probiert. Ich vermute dass es ein Fehler ist, mindestens aber bedarf es einer Doku-Ergänzung. Ich nehme das daher erstmal als Bug auf.


Danke für's Finden und Nennen des Workarounds. 👍


Die Deaktivierung des Validators hat zur Folge, dass die Email-Eingaben in der Kontakt-/Nutzerdatenpflege nicht mehr geprüft werden. Wenn aber vorwiegend das AD/LDAP für Kontaktdatenquelle benutzt wird, ist das sicherlich hinnehmbar.


CU, Torsten