@davidschilling Also es sind verschieden Tools bzw. Zugriffsversuche.

das eine ist der Zugriff über Windows IE Explorer Platform
https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/ms775123(v=vs.85)

Das andere ist eine Komponetensammlung:
TMS VCL Cloud Pack
https://www.tmssoftware.com/site/cloudpack.asp

Beide gehen nicht.

Die dritte Variante die ich nun habe ist über Indy-Komponenten:
https://www.indyproject.org/about/
dort funktioniert es.

Ich kann mich da meinen Vorrednern nur anschließen. Es macht leider echt keinen Spaß und ist defakto fast unmöglich mit der Openapi.json zu arbeiten, weil so viele Fehler drin sind. Zudem bin ich etwas frustriert, was die Antwortzeiten angeht, wenn man einen Fehler in der Openapi.json meldet.

@hbuerger Was war das Ergebnis vom "angucken"?

Hat sich da seit April was getan? Möchtet ihr, dass wir als Entwickler aktiv Fehler melden oder empfindet ihr das eher als nervig? Wie können wir als externe Entwickler diese Fehler so melden oder sogar selbst korrigieren, dass sie schneller im Produktiv-System landen?

@skipy sagte in Openjson Fehler: person/masterdata:

Oder noch besser:
Nach meinem Verständnis bräuchte es in der Openapi.json bei boolean Werte gar kein enum. Per Definition können Werte vom type boolean nämlich nur true oder false sein.

Du steigst da gut und tief ein. Vielen Dank. Es sind oft diese Kleinigkeiten, die einem das Leben schwer machen. Ähnliche Probleme gibt es manchmal mit IDs, die mal als Integer und mal als String zurückkommen.

Apropos Bool: Ich persönlich würde ja empfehlen auf bool ganz zu verzichten. Irgendwann kommt mal ein Fall hinzu wo man nicht mehr nur zweiwertig unterwegs ist. In der Regel braucht noch noch einen Neutralwert wenn man da nicht null nehmen will. Daher fände ich das mit den enum schon besser (und zukunftssicherer)

@ernst-egb beim support melden, dann wird der LDAP Dienst eingerichtet.

@davidschilling ok, das heißt man muss ständig eine neue Gottesdienstserie anlegen? Wie lange wäre denn die längste mögliche Serie? Ich kann das leider selbst nicht überprüfen, da ich nur einen Gastzugang zu einer Churchtools Instanz habe.

@markusp du kannst auch den Endpunkt /persons?ids[]=..... verwenden, dann ist es nur ein Aufruf die Dokumentation findest du unter deineGemeinde.church.tools/api

@jziegeler danke, schon mal gut, dass ich so direkt einladen kann zu CT in die Gruppe. Langsam begreife ich das CT – Konzept, entscheidend sind oft die Berechtigungen. Alles klar erst mal! Danke euch! 👌

@jziegeler
danke dir, dort hätte ich es nicht erwartet.

Gibt es einen Grund, warum man das Recht zum "Berechtigungen anpassen" (administer persons) benötigt? Mit dem API Call kann ich ja keine Berechtigung ändern, sondern nur eine Personenliste (nur die ID) abholen.

"Administer persons" und "Berechtigung anpassen" sind doch zwei komplett unterschiedliche Sachen. Die Rechteverwaltung beziehen sich ja auch auf Status, Gruppentypen und Gruppen. Da ist "administer groups" hier schon viel verständlicher: Gruppen administrieren, d.h. erstellen, löschen, etc.

Leider verhält sich der API Call nicht so wie ich es erwartet hätte. Ich dachte, dass dort dann nur die für den Benutzer sichtbaren Personen zurück geworfen werden, aber es werden auch für ihn nicht sichtbaren User zurück gegeben. Dann muss ich mir hierfür etwas anderes überlegen.

@markusp für application/json ist es nicht notwendig.

CSRF ist eine Sicherheitslücke die über Formulare in Browsern passieren kann. Wenn du einen ajax request im browser machst kannst du keinen csrf ausnutzen.

@aschild Das wäre auszuprobieren.

Du kannst aber sicher ein neues Feld mit dem neuen Namen anlegen und einen wenigzeiler schreiben, der das umkopiert.

@gabi sagte in Schnittstelle zu Mailpoet:

In diesem Forum wird ständig Fachsprache benutzt, die nicht erklärt wird.

Oh, ok. Einfach immer nachhaken, wenn etwas unverständlich ist.

@davidschilling Ich habe versucht, das Passwort in JSON zu senden. Sobald aber bestimmte Sonderzeichen enthalten sind, erhalte ich "Passwort ist falsch" zurück.

$url = 'https://xxx.church.tools?q=login/ajax&func=getUserLoginToken'; $data = array( 'email' => $email, 'password' => $password, 'directtool' => 'yes' ); $options = array( 'http' => array( 'method' => "POST", 'header' => "Content-type: application/json" ."\r\naccept: application/json", 'content' => json_encode($data) ) ); $context = stream_context_create($options); $result = file_get_contents($url, false, $context); $data = json_decode($result);

@hgransow du brauchst vor der alten api keine Angst zu haben. Wen man mal weiß wie es geht, kommt man damit auch gut klar.

und bis CT komplett auf der neuen API ist wird es m.E. noch einige Zeit dauern (bis dahin ist REST schon wieder old school 🙂

Ich hab mich mit api V1 arrangiert. Seien wir doch froh, dass sie schon JSON liefert.

@davidschilling sagte in Abfrage bzw. setzen der Permissions per API:

schau am besten mal in eurem ChurchTools Log nach ob dort ein Fehler sichtbar ist.

warum bin ich auf die Idee nicht selbst gekommen? Da stand die Lösung: Der will als data echt einen json-String sehen, der dann nochmal beim Senden nochmal mit http_build_query verpackt werden muss.

vielen Dank für den Hinweis.

Support hat gentwortet:

Mar 23, 15:29
Hallo,

wir haben es noch mal geprüft und ja die Tabelle wird wirklich nicht vernünftig aufgeräumt. Es gibt nach unserer Einschätzung keine Seiteneffekte, daher ist es nicht schlimm. Danke für den wertvollen Hinweis. Wir haben es als Bug aufgenommen und werden das beheben.

@jziegeler Vielen Dank für den Hinweis. Da hat aber jemand eine Abkürzung genommen 🙂

Mein Recheteauswerteprototyp funktionier da sogar zufällig (im wahrsten sinne des wortes ...) weil er die gruppen ohne Typprüfung der ID sucht, und daher über "10101" auch "10101D" findet.

Ich werte die Jsons über JSONpath aus.
$__authrecord = $masterdata_jsonpath->find("$..auth_table..[?(@.id=='$_auth_key')]")[0];

Das läuft gut und ist für meine Anwendung ausreichend schnell obwohl da zwei "deep serach operationen" drin sind ..

Auch in diesem Fall ist der Browser wieder unser Freund und kann uns helfen zu verstehen wie man Cookies sendet.
Einfach mal die Entwicklerkonsole im ChurchTools Frontend öffnen und die Header eines Requests anschauen.

Schlussendlich muss das Cookie als Header geschickt werden. Hier die Dokumentation von Mozilla dazu: https://developer.mozilla.org/de/docs/Web/HTTP/Headers/Cookie

curl_setopt($ch, CURLOPT_HTTPHEADER, array("Cookie: ct_testdavid=bizlub34qv5b03457nqvb3547"));