Beispiel eines API Aufrufes
-
Hi,
zunächst mal großen Dank für dieses wirklich sehr nützliche und auf unsere Bedürfnisse passende Tool!
Leider komme ich mit der "API-Dokumentation" nicht so wirklich zurecht. Ich versuche gerade, eine OO-Kapselung in PHP 7 zu bauen (https://github.com/vineyardkoeln/churchtools-api), um die Verwendung zu vereinfachen. Fernziel ist die Integration von ChurchTools mit unserem Slack Workspace - zunächst mal Leute per Slack-Nachricht an ihre Dienste erinnern, in der Endausbaustufe dann hoffentlich auch mit einem Chat-Bot, über den man Dienste eintragen oder tauschen kann.
Jedenfalls werde ich aus der automatisch generierten Doku nicht so ganz schlau. Das ist ja eher eine Code-Doku, nur ohne Quellcode schwierig nachzuvollziehen. Manche Funktionen lassen sich über die API aufrufen mit "func=xxx", z.B. getAllEventData in ChurchService. Andere Funktionen wie "getServicesForEvent" sind nicht öffentlich und erzeugen eine Fehlermeldung. Hilfreich wäre es da, wenn in der ApiDoc mit dem PhpDoc-Tag @api gekennzeichnet wäre, welche "func"s die API unterstützt. Richtig genial wäre natürlich eine richtige RESTful API mit entsprechender Swagger-like Doku... aber solange ich an die Daten komme und alles klappt, nice to have.
Gerade stehe ich vor dem Problem, dass ich alle Dienste und Belegungen zu den anstehenden Events bekomme, aber nur mit einer Service-ID. Jetzt bräuchte ich halt einfach noch eine Route, die mir das Mapping Service-ID -> Name zurückliefert. Wo finde ich die?
Viele Grüße
Jörn -
Die solltest Du mit getMasterdata bekommen können.
-
Hallo Miteinander,
der Thread ist zwar schon etwas älter, aber ich dachte ich gebe trotzdem meine Lösung weiter, falls es jemand anderes eine Hilfe ist.
Ich habe eine kleine Proxy-Umgebung programmiert. Sie wird auf dem eigenen Server installiert und leitet die Anfragen direkt weiter an den ChurchTools Server. Dadurch müssen keine Zugangsdaten via JavaScript übertragen werden und die die Browser-CORS Probleme werden richtig gehandhabt. Das Proxy-Projekt ist hier zu finden: https://github.com/stevenbuehner/ChurchToolsProxyServer
Wer sich außerdem gerne mit VueJs beschäftigt, findet hier eine Vorlage um schnell eine kleine VueJs Applikation für ChurchTools zu programmieren. Sie ist auf den oben genannten ProxyServer abgestimmt und hier zu finden: https://github.com/stevenbuehner/ChurchToolsVuejsClientExample
Das Beispiel zeigt eine einfache Auflistung der nächsten anstehenden Termine im Kalender, sortiert nach Datum und eingefärbt mit den ChurchTools Kalenderfarben. Sie ist gedacht um z.B. auf einem großen Bildschirm oder Pad die nächsten Gemeindetermine anzuzeigen ...
Viel Freude damit.
Steven -
Das Thema hier ist zwar schon etwas älter, aber gerade deswegen würde ich doch gerne wissen, wie es nun um Access-Control-Allow-Origin steht. Wurde da was von seiten Churchtools gemacht, oder ist das immer noch der gleiche "pain" wie 2017?
Ist ja jetzt keine Seltenheit, dass eine Gemeinde den öffentlichen Kalender vom Churchtools in die eigene Homepage einbinden will und das ohne iframe.
-
Ist es hier im Forum normal, dass keiner von Churchtools antwortet?
-
@DNie best practice ist diese Requests durch das eigene Backend zu leiten.
"pain" hätte ich, würde CT den Access-Control-Allow-Origin auf * setzen
Mal im Ernst, warum sollte jede x-beliebige Seite Requests auf CT machen dürfen (und das Ergebnis verwenden)? -
@Marcel sagte in Beispiel eines API Aufrufes:
"pain" hätte ich, würde CT den Access-Control-Allow-Origin auf * setzen
Mal im Ernst, warum sollte jede x-beliebige Seite Requests auf CT machen dürfen (und das Ergebnis verwenden)?Gewissermaßen gebe ich dir recht. Auf der anderen Seite ist es ja ein leichtes, Access-Control-Allow-Origin anpassbar zu machen.
Ich sehe nicht, dass es wirklich Sinn macht, bei einer Gemeindeseite, welche eigentlich kein Backend benötigt, noch ein Backend, nur für den öffentlichen Kalender hoch zu ziehen.
Irgendeine Lösung muss es da ja geben, außer über das Backend. -
Wir haben in ChurchTools bewusst erstmal keine
CORSHeader gesetzt. Denn wie auch @Marcel richtig sagt, ein*Header würde mehr Schaden als Nutzen anrichten.Wir arbeiten gerade unter Hochdruck an einer REST API. Ob wir in diesem Zuge unsere
CORSPolitik ändern müssen wir intern erstmal besprechen und abwegen. Daher kann ich dir hier zu erstmal keine weiteren Infos geben.Aber falls (das ist kein Versprechen) wir CORS erlauben, dann nur unter bestimmten Auflagen und wir werden sicherlich nicht einfach für alle CT Installationen das aktivieren. Wie das im genauen Aussehen könnte ¯_(ツ)_/¯
Aktuell kann ich dir leider auch nur sagen, dass ein Backen oder iFrame deine Lösungen sind. Tut mir leid, dass ich dir hier erstmal nicht weiter helfen kann. Sicherheit geht aber vor Bequemlichkeit erstmal vor, ich hoffe du verstehst das
Ich verspreche dir aber, dass ich das intern in die Entwickler-Runde trage und dass wir das Thema noch mal besprechen werden. -
@hbuerger gibt es hier inzwischen etwas neues?
-
Wir haben hier tatsächlich mittlerweile eine Möglichkeit. Diese funktioniert aber nur über die churchtools.config. Hier ein Beispieleintrag:
access_control_allow_origin=http://test.churchWen du Hoster bist kannst du dich an den Support wenden um das einzustellen.
-
@davidschilling sagte in Beispiel eines API Aufrufes:
Wir haben hier tatsächlich mittlerweile eine Möglichkeit. Diese funktioniert aber nur über die churchtools.config. Hier ein Beispieleintrag:
access_control_allow_origin=http://test.churchWen du Hoster bist kannst du dich an den Support wenden um das einzustellen.
Geht das auch, wenn ich nicht selbst hoster bin?
-
Als Hoster Info an den Support, als Selfhoster kann man das selber eintragen.
