@jziegeler: Hallo, richtig, der iCal fkt. einwandfrei. Wg. Cronjob muß ich mal mit dem Server-Admin sprechen. Ich hab keine Ahnung, was da zu tun ist. Gruß, Gerald

@jziegeler Cool! Vor allem, wenn man das aus seinem Kalender automatisch vorbelegen kann. 😉

Die Planung über CT schau ich mir mal an. Danke für die Hinweise!

Gibt es ein paar Codeschnipsel, mit denen ich so einen Upload/POST tortzdem mal probieren kann?

So, ich habe eine für uns brauchbare Lösung gefunden 🙂
Da wir Churchtools selbst hosten und es sich bei der gesuchten Funktion IMMER um die Freigabe eines Serientermins handelt, kann ich die Aufgabe ganz einfach dadurch lösen, indem ich direkt in die Datenbank in die Tabelle cc_cal_except eine Terminausnahme rein schreibe.
Ist zwar nicht ganz so schön wie über eine offizielle API Funktion, hilft uns aber erst mal weiter.

Vielen Dank!

ich vermute es liegt an dem fehlenden CSRF-Token.
Hier genauer beschrieben: https://intern.church.tools/?q=churchwiki#WikiView/filterWikicategory_id:0/doc:API-CSRF/follow_redirect:true/

Das ist aber schon seit einigen Versionen so.

@hbuerger Das ist schade. Ich werde also als zwischenLösung den Veranstaltungsraum nochmal in die agenda schreiben, denn für unsere Anwendung brauche ich dann auch noch die Bestuhlung usw.

@davidschilling ich verwende PHP. An die Einbindung der Vinyard - API hab ich mich noch nicht getraut, weil ich hoffte mit etwas leichtgewichtigerem hinzukommen.

Ich integriere die Scripte in Contao, schreibe aber keine Extension sondern rufe nur einzelne Scripte auf. Da ich mich mit composer nicht auskenne, mach ich noch einen bogen um so solche Bibliotheken, die ich (vermutlich zu Unrecht) als schwergewichtig empfinde.

@merkles-icf schau dir vielleicht mal hier die Hilfeseite an, das ist ein guter Start: https://intern.church.tools/?q=churchwiki#/WikiView/filterWikicategory_id:0/doc:API/follow_redirect:true/

Das ist eindeutig falsch. Danke. Ich pass es an, dass hier date-time und das Zulu Format verwendet wird.

PS: Ich finde es super, wenn ihr solche Fehler meldet. Es ist leichter für mich, wenn ihr auch gleich den jeweiligen Endpoint nennt, dann muss ich nicht suchen 🙂

@davidschilling danke!

@aschild Danke für den Hinweis. Der wäre in der aktuellen Version des Vineyard Köln API-Clients eigentlich schon implementiert gewesen, aber aus irgendeinem Grund hat Composer bei mir nicht auf die neuste Version aktualisiert.
Jetzt geht es aber wieder.

Hi,
das Thema hat sich mittlerweile erledigt. Danke trotzdem für die schnelle Antwort. Mit Postman hat der Request funktioniert, da der Postman-Client die Cookies sichtlich speichert.

Da ich den Ablauf jetzt aber Server-seitig durchführen lasse, gibt es keine Komplikationen mehr. Ich brauchte nur etwas Einarbeitungszeit in die Materie.

Liebe Grüße aus Berlin und alles Gute für die Zeit der Krise 🙂

@fodinabor
HERZLICHEN DANK! Das hat mir sehr geholfen.

Nein, du bist nicht blind. Diese Filterfunktion nach Bereich gibt es zurzeit noch nicht.

@Silas-K sagte in Beispiel Login REST API:

Nachtrag:
Bzw. Anders gefragt, von wo darf denn ein Zugriff auf die API stattfinden, wenn Postman es schafft, aber meine PWA nicht?

Kurze Ergänzung dazu. CORS (Mozilla MDN) ist ein Schutzmechanismus im Web. Ganz einfach gesprochen: Der Browser verhindert das nachladen von Daten (Skripts, CSS, API Calls, etc.) wenn der Origin (in diesem Fall ChurchTools) diese Seite nicht explizit das Laden erlaubt. Damit soll verhindert werden, dass im Frontend Schadcode von fremden Quellen einfach so geladen werden kann.

Wenn du PHP verwendest, dann läuft das auf einem Server. Backend also hier kannst du die ChurchTools API ohne Probleme aufrufen. Dass dein Server gehackt wurde und Schadecode ausliefert ist eher unwahrscheinlich.

Es lohnt sich das Thema CORS anzugucken. So ist es doch ein wichtiges Sicherheitskonzept im Web.