Resourcenbelegung via php curl_exec abfragen

hbuerger

Paar Fragen.

Welche URL verwendest du? Kannst du uns ein ganzes Code Beispiel zeigen
Musst/Willst du curl verwenden? Es gibt das Package Guzzle, damit lassen sich etwas einfacher Requests in PHP schreiben. Curl ist da etwas unhandlich
Wie authentifizierst du dich genau? -> Schickst du den Session Cookie mit?
Geht es um die AJAX oder die REST API?

bwl21

@hbuerger 1. Die URL https://{meinekirche}.church.tools/?q=churchresource/ajax&func=getBookings&login_token=qd*...

ich muss nicht curl verwenden, hab aber bei m REST damit angefangen und treibe es halt weiter. Ich habe mir eine Komponente geschrieben, welche den Zugriff auf CT wrappt. Das funktioniert für REST ganz hervorragend, bei AJAX habe ich die erwähnten Probleme. Guzzle kannte ich nicht, ich bin eher ein Freund PHP plain zu verwenden. Aber ich schau es mir an.
Ich schicke bei jedem Aufruf das login_token mit. Ich vermute, darin liegt das Problem. Irgendwie müsste ich vermutlich curl dazu bringen, ein session-token mitzuliefern, und einen ordentlichen Login/Logout-Vorgang zu machen. bei meinen REST-Aufrufen mach ich das aber auch nicht. Ist vermutlich nicht optimal, wenn jeder Aufruf einen neuen Login. macht.

Access-token habe ich als Admin in den Berechtigungen dieses Accounts ausgelesen.
ich verwende normalerweise das REST-API. Damit funktioniert auch alles. Da dieses aber die Ressourcenbelegung nicht liefert, habe ich mich doch noch ans ajax-API gewagt.

ich habe gerade mal die guzzle doku überflogen. Würde es damit gehen, dass ich die genannte URL da einfach absetze? Dann würde ich das hernehmen. Meine eigene Komponente macht auch nicht viel anderes, vermutlich aber bei weitem nicht so umfänglich, weil meine Ahnung da auch begrenzt ist.

bwl21

Das ist de Methode, mit der ich den curl absetze ... das sind noch ein par debug echos drin

    /**
     * This method invokes the ajax api from ct
     *
     *
     * @param $command
     * @param $component
     * @param $query_data
     * @param array $headers
     *
     * example
     *
     * ajax("GET", "churchcal", ['func'->"getCalPerCategory", 'category_ids=[5,6]])
     */

    function ajax($command, $component, $query_data, $headers = [])
    {
        $query = $query_data;
        $query['login_token'] = $this->apisecret;
        $params = http_build_query($query);
        $url = "{$this->cturl}/?q={$component}/ajax&{$params}";


        $curl = curl_init();

        curl_setopt($curl, CURLOPT_URL, $url);
        curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
        curl_setopt($curl, CURLOPT_HEADER, true); //if you want headers
        curl_setopt($curl, CURLOPT_HTTPHEADER, $headers);
        curl_setopt($curl, CURLOPT_FOLLOWLOCATION, true);

        if ($command == 'POST') {
            curl_setopt($curl, CURLOPT_POST, 1);
        }

        echo ("<br/>".print_r(curl_getinfo($c), true));

        $result = curl_exec($curl);
        echo ("<br/>".print_r(curl_getinfo($c), true));


        echo ("<pre>result: ".print_r($result, true) . "</pre>");

        if (curl_errno($curl)) {
            $result = curl_error($curl);
        } else {
        }

        curl_close($curl);

        return json_decode($result, true);
    }

davidschilling

Was dir vermutlich fehlt ist das CSRF-Token. Das wird beim Aufruf der alten Api benötigt.
Das sendet man als Header csrf-token mit.

Das Token kannst du dir mit /api/csrftoken holen.

Generell solltest du aber auch die Session Cookies die ChurchTools sendet nutzen und nur im Login Fall das Login-Token nutzen, sonst machst du mit jedem Api-Call eine neue Session auf.

Hier gibt es noch ein paar mehr Details dazu: https://intern.church.tools/#WikiView/filterWikicategory_id:0/doc:API-CSRF/follow_redirect:true/

bwl21

@davidschilling vielen Dank. Ich muss mal schauen wie das mit den Cookies bei einem headless aufruf funktioniert. Ich probiere das aus und schreib hier über die Ergebnisse.

bwl21

@davidschilling sagte in Resourcenbelegung via php curl_exec abfragen:

Das Token kannst du dir mit /api/csrftoken holen.
Generell solltest du aber auch die Session Cookies die ChurchTools sendet nutzen und nur im Login Fall das Login-Token nutzen, sonst machst du mit jedem Api-Call

Ich sehe noch nicht ganz, wie der login/logout-vorgang geht.

Verstehe ich richtig, dass ich mich sozusagen mit

/api/csrftoken einlogge und dabei das login-token mitschicke
in allen folgenden Aufrufen das csrftoken im header und auch das beim ersten Aufruf empfangene Cookie mitschicke
Zum Beenden der Session ??? gibt es einen Call zum logout oder wird da einfach auf den timeout gewartet.

hbuerger

Nein der CSRF Token ist kein Login-Token, sondern ein Token, um Formulare zu verifizieren. Es geht hier um eine sogenannte Cross-Site Request Forgery Attacke (MDN - CSRF).

Du musst diesen CSRF Token abfragen und mit den POSTs bei der alten API mitschicken. Das ist ein Sicherheits-Token. Informiere dich über CSRF, dazu gibt es viele Ressourcen im Internet.

Wenn du von Einloggen sprichst müssen wir hier unterscheiden.

Mit Benutzernamen + Passwort, dann verwende die /login Endpoints, um eine Session zu generieren
Mit Login Token. Den kannst du (seit v.3.70) einfach als Authorization: Login <token> Header mitschicken. Dann wirst du automatisch "eingeloggt"

bwl21

Dieser Beitrag wurde gelöscht!

hbuerger

Guck mal hier https://intern.church.tools/?q=churchwiki#WikiView/filterWikicategory_id:0/doc:API-CSRF/follow_redirect:true/

Und hier https://intern.church.tools/?q=churchwiki#WikiView/filterWikicategory_id:0/doc:API/follow_redirect:true/

bwl21

@hbuerger sagte in Resourcenbelegung via php curl_exec abfragen:

Guck mal hier https://intern.church.tools/?q=churchwiki#WikiView/filterWikicategory_id:0/doc:API-CSRF/follow_redirect:true/

Und hier https://intern.church.tools/?q=churchwiki#WikiView/filterWikicategory_id:0/doc:API/follow_redirect:true/

Vielen Dank für die Links. Nun bin ich etwas weiter. https://github.com/fodinabor/CT-API-Tools hat mir geholfen. Das Teil von Vinyard Köln scheint mir professioneller und viel umfangreicher. Vor allem scheinen die Leute V1 und V2 wegzukapseln ...

Für mich ist es aber vielleicht zu komplex zumal ich das ja dann wieder in unser CMS integrieren muss. Da trau ich mich nicht so recht dran. Drum versuche ich erst mal die einfach-Variante.

Jetzt bin ich am nächsten Punkt: ich versuche nach https://api.church.tools/index.html die API - funktionen zu machen.

Zum Beispiel nach https://api.church.tools/function-getBookings.html

/**
 * @param $domain
 * @return mixed
 */
function CT_getRessourceBookings($domain)
{
    $url = $domain . 'churchresource/ajax';
    $data = array('func' => 'getBookings', 'from' => "0", 'to' => "1");
    $ret = CT_sendRequest($domain, $url, $data);
    return $ret;
}

CT liefert aber immer alle Buchungen und nicht nur die von heut und morgen, d.h. die parameter from und to greifen irgendwie nicht.

https://api.church.tools/index.html überhaupt richtig?

hbuerger

@bwl21 Musste eben im Code nachgucken. Ja, da ist aktuell ein Bug drin. Die Parameter werden von der API nicht berücksichtig. Ich nehm, dass als Bug auf.

Akutell bleibt dir leider übrigt, die Einträge manuell zu filtern.

bwl21

@hbuerger vielen Dank, dann weiß ich bescheid. Das filtern ist kein problem. Wir wollen das alle 1-3 Stunden laufen lassen.

verstehe ich richtig, dass ich mit https://api.church.tools/index.html arbeiten kann.

hbuerger

@bwl21 Nur damit wir nicht an einander vorbei reden.

https://api.church.tools/index.html ist "nur" die "Dokumentation" der alten AJAX API. Dort kannst du nachgucken, welche Funktionen mit welchen Parametern man theoretisch aufrufen kann.

Allerdings wurden die Dokumente meines Wissens nach schon lange nicht aktualisiert (auf der anderen Seite hat sich auch nicht viel daran geändert).

bwl21

@hbuerger ja, das habe ich verstanden. Ich versuche, möglichst mit dem V2 API zu arbeiten, wenn ich was unbedingt brauche, nehme ich das V1 Api und hoffe dass es tut:-)

bwl21

@hbuerger Ich komme in der Sache weiter ...

Die Parameter werden von der API nicht berücksichtig. Ich nehm, dass als Bug auf.

Damit kann ich leben. Eine andere Frage, ist, ob es auch die Möglichkeit gibt, Wiederholungstermine aufgelöst zu bekommen, sonst muss ich das alles nachrechnen.

hbuerger

@bwl21 sagte in Resourcenbelegung via php curl_exec abfragen:

Wiederholungstermine aufgelöst zu bekommen, sonst muss ich das alles nachrechnen.

Nein, dass ist nicht möglich. Die Wiederholungen musst du aktuell selber berechnen. Liegt an der internen Datenhaltung.

bwl21

@hbuerger sagte in Resourcenbelegung via php curl_exec abfragen:

Nein, dass ist nicht möglich. Die Wiederholungen musst du aktuell selber berechnen. Liegt an der internen Datenhaltung.

Danke für die schnelle Antwort. Gibt es eine Dokumentation, wie das zu machen ist, vielleicht sogar eine Beispielfunktion (egal ob JS of PHP)? Oder muss ich das "reverse engineeren"?

Wie komme ich an die Masterdaten von ressource?: repeat_option_id, status_id

hbuerger

Ich mach es kurz:

1. MasterData

func = getMasterData Gibt alle Stammdaten im Modul zurück (Auch alte AJAX API)

2. Wiederholung

Hier mal eine Buchung wie sie die API zurück gibt und wie es im Frontend aussieht

Bildschirmfoto 2021-03-09 um 09.27.36.png

{
    "status": "success",
    "data": {
        "124": {
            "id": "124",
            "cc_cal_id": null,
            "resource_id": "5",
            "person_id": "1",
            "startdate": "2021-03-08 12:00:00",
            "enddate": "2021-03-08 13:00:00",
            "repeat_id": "1", 
            "repeat_frequence": "1",
            "repeat_until": "2021-03-12 00:00:00",
            "repeat_option_id": null,
            "status_id": "2",
            "text": "Serie",
            "location": "",
            "note": "",
            "show_in_churchcal_yn": "0",
            "modified_date": "2021-03-09 09:25:45",
            "create_date": "2021-03-09 09:25:45",
            "person_name": "Hans-Helge Bürger ö ä Ä",
            "station_id": "0",
            "bezeichnung": "Raum 01",
            "version": "0",
            "exceptions": {
                "10": {
                    "id": "10",
                    "booking_id": "124",
                    "except_date_start": "2021-03-10 00:00:00",
                    "except_date_end": "2021-03-10 00:00:00",
                    "userid": "",
                    "modified_date": "2021-03-09 09:25:46",
                    "modified_pid": "1"
                }
            }
        }
    }
}

startdate und enddate definieren, Startzeit und Endzeit des Termins. Also Anfang vom Meeting und Ende vom Meeting
repeat_id Welche art der Wiederholung (Täglich, wächentlich ...)
repeat_frequence Wie oft die Wiederholung stattfindet
repeat_until Bis wann soll wiederholt werden
exceptions Object mit den Ausnahmen, wann diese Wiederholung nicht stattfindet

jziegeler

Kurzes Update: der Bug im Filter wird in der Version 3.71 (vermutlich ab 22.03.) gefixt sein