ChurchTools API Client (PHP)

sctech

@dumbergerl Sehr gute Ergänzung, danke!

Es gibt wohl noch keine dokumentierte Methode, dies über die REST API (anstelle der alten AJAX API) zu tun? Weiss da jemand mehr?

Ich hatte bisher auch immer nur eine Krücke angewendet:

GET Request: /api/whoami
URL-Parameter: user_id, login_token
... danach das Session Cookie für weitere Anfragen übernehmen

Aber eben - eigentlich müsste es doch hierfür einen offiziellen Endpoint geben?

BiKi

@sctech nein, soweit ich weiß, gibt es dafür (noch) keine Rest-API… mache das auch über die Ajax-API…

narnitz

@sctech sagte in ChurchTools API Client (PHP):

@dumbergerl Sehr gute Ergänzung, danke!

Es gibt wohl noch keine dokumentierte Methode, dies über die REST API (anstelle der alten AJAX API) zu tun? Weiss da jemand mehr?

Ich hatte bisher auch immer nur eine Krücke angewendet:

GET Request: /api/whoami
URL-Parameter: user_id, login_token
... danach das Session Cookie für weitere Anfragen übernehmen

Aber eben - eigentlich müsste es doch hierfür einen offiziellen Endpoint geben?

Bei /api/login bekommst du entweder status=sucess zurück oder status=totp
Hier bekommst du auch die personId

Falls zweiteres ist folgendes der flow für den neuen API (hier beispielsweise mit dem churchtoolsClient):

churchtoolsClient.post('/login/totp', {
	code,
	personId
});

Da solltest du dann den Token bekommen.

sctech

@narnitz Danke - dieser Fall ist klar und auch bereits so implementiert. Die Frage war, ob es keinen Endpoint gibt, welcher den Login mit UserID und Token erlaubt. Der Endpoint /login funktioniert ja „nur“ mit Benutzername und Passwort.

Ralf Bürzele

@sctech Wenn Du den Logintoken hast, brauchst Du Dich nicht einloggen, Du hängst den Token nur an jeden Request an.

narnitz

@ralf-bürzele Genau.

DumbergerL

@ralf-bürzele Stimmt es wäre ein Möglichkeit den Login-Token einfach jedes Mal an den Request zu hängen (im Header oder Query). Das hatte ich in der initialen Version auch so implementiert. Allerdings habe ich von ChurchTools die Rückmeldung, dass dann bei jedem Aufruf die Berechtigungen neu errechnet werden müssen. Performanter ist es, den Session-Cookie für die Authentifizierung von mehreren Requests zu verweden. Deshalb nutze ich den Login-Token jetzt nur für einen ersten Request um den Session-Cookie zu erstellen, der dann für alle weiteren Requests verwendet wird.

Im API Client stehen jetzt folgende Authentifizierungmethoden (siehe Docs) zur Verfügung:

...E-Mail und Passwort:

$auth = CTConfig::authWithCredentials($email, $password);

...E-Mail und Passwort mit Multi-Factor Authentication:

$auth = CTConfig::authWithCredentials($email, $password, $totp);

...mit User-ID und Login-Token (alte Ajax-API)

Wie @BiKi sich gewünscht hat (wobei für dich vermutlich auch Punkt 4 funktionieren würde?)

$success = CTConfig::authWithUserIdAndLoginToken("29", "<login-token>");

...mit Login-Token (via REST-API):

Wie @Ralf-Bürzele richtig vorschlägt:

$auth = CTConfig::authWithLoginToken("<login-token>");

Hinweis: Die Methoden getApiKey() und setApiKey() wurden als deprecated markiert und werden im nächsten Major-Release entfernt. Der Getter lässt sich durch AuthRequest::retrieveApiToken() ersetzen und der Setter durch CTConfig::authWithLoginToken().

BiKi

@dumbergerl vielen Dank!

Ja für mich würde auch der Login mit Logintoken (ohne LoginId) reichen, das hatte ich so nicht auf dem Schirm, dass das auch so möglich ist…

Ralf Bürzele

@dumbergerl ah, gut zu wissen. Dann werde ich bei meiner Implementation auch nach der ersten Verwendung des logintokens dann mit den cookies weiterarbeiten.

Ralf Bürzele

@sctech Doch, gibt es. Man kann (vermutlich) jede REST-API-Funktion nehmen, den LoginToken anhängen und zurück kommt ein Session-Cookie, das man weiter verwursten kann. Eben mit /whoami getestet.

sctech

@ralf-bürzele Ja, genau - wie oben beschrieben, mache ich dies bisher auch immer über /whoami und verwende dann für folgende Abfragen den Session Cookie.

GET Request: /api/whoami
URL-Parameter: user_id, login_token
Login erfolgreich, sofern als id dir korrekte User ID zurück kommt.

@DumbergerL Vielleicht wäre dies auch für den API Client eine passende Variante, sodass für CTConfig::authWithUserIdAndLoginToken() nicht mehr die alte API benötigt wird?

DumbergerL

@sctech Da hast du grundsätzlich Recht, das wäre eine Möglichkeit. Ich habe allerdings die Methode CTConfig::authWithUserIdAndLoginToken() bereits auf deprecated gesetzt und werde Sie mit dem nächsten Major-Release wieder entfernen, nachdem die Methode CTConfig::authWithLoginToken() ja dasselbe tut ohne eine User-ID zu benötigen.

Ralf Bürzele

@sctech /whoami braucht doch keine UserID? oder willst Du nur sicherstellen, daß Du Du bist?

sctech

@dumbergerl Alles klar, das macht Sinn - danke!

@Ralf-Bürzele Ja, genau - bisher habe ich damit immer sichergestellt, dass ich ich bin. Damit war dann der Login erfolgreich. Der API Client prüft mit CTConfig::authWithLoginToken() nun auf eine gültige ID (nicht leer und nicht -1). Das passt aus meiner Sicht genauso.

sctech

@dumbergerl Ich stehe vor der Herausforderung, dass ich in derselben Anwendung gleichzeitig auf folgendes zugreifen will:

gleiche ChurchTools-Installation, verschiedene authentifizierte Benutzer
unterschiedliche ChurchTools-Installationen (zum Datenaustausch)

Wenn ich das richtig sehe, ist das aktuell nicht möglich, weil ich ja nicht mehrere Objektinstanzen des API Clients erstellen kann. Ist das korrekt - oder sehe ich das falsch?

Zudem müsste dann auch das Caching pro ChurchTools-Installation und User separat erfolgen.

Eine Idee, wie ich das umsetzen kann?

Zum Thema Caching eine andere Frage:
Standardmässig wird das ja auf File-Ebene gemacht. Für die Implementierung in einem WordPress-Plugin wäre allerdings die Verwendung von WordPress-Transienten wünschenswert. Wie kann ich den Caching-Mechanismus beeinflussen?

Danke fürs Weiterhelfen und eure Ideen!

DumbergerL

@sctech Ich habe schon ziemlich am Anfang des Projekts darüber nachgedacht den Client mit verschiedenen Sessions auszustatten. Bisher kam die Anforderung allerdings noch nicht auf, weshalb ich das noch nicht umgesetzt habe.

Alle statischen Methoden (z.B. CTConfig::setApiUrl(), PersonRequest::whoami(), ...) auf Objektmethoden ($ctConfig->setApiUrl(), $personRequest->whoami()) umzuziehen um verschiedene Sessions zu instanziieren fällt aufgrund der Rückwärtskompatibilität eigentlich raus.

Aber wie wäre es, wenn man zwischen verschiedenen Sessions wechseln kann?

// default session:
$myself = PersonRequest:whoami();
...
// switch session:
CTSession::switchSession("person_a_session");
$myselfPersonA = PersonRequest:whoami();

Ich habe das Ganze auch am entsprechenden Issue beschrieben: https://github.com/5pm-HDH/churchtools-api/issues/2 Gib gerne Rückmeldung, ob das für dich eine mögliche Lösung wäre?

Bezüglich des Caching habe ich auch einen Issue angelegt: https://github.com/5pm-HDH/churchtools-api/issues/169 Ich würde vorschlagen wir implementieren das PSR-6 Caching-Interface, damit man von außen eine andere Caching-Bibliothek injektieren kann. Mit einem Adapter kann man dann ebenfalls Wordpress Transient anbinden. Wann ich zur Umsetzung komme ist offen.

sctech

@dumbergerl danke für deine Rückmeldung! Verschiedene Sessions verwenden zu können, wie du es im Issue beschrieben hast, wäre für mich eine schöne und praktikable Lösung. Das würde mir sehr dienen!

Bzgl. Caching: Die Möglichkeit zur Implementierung eigener Adapter gefällt mir gut. Für mich persönlich hat diese Sache geringe Priorität.

DumbergerL

@sctech das Thema Multi-Session habe ich jetzt umgesetzt:

Siehe Doku: https://github.com/5pm-HDH/churchtools-api/blob/master/docs/out/CTConfig.md#3-ct-session

Ich hoffe das hilft dir weiter!

sctech

@dumbergerl TOP! Vielen Dank - das ist echt ein grosser Mehrwert! Werde das gleich nächste Woche mal in einem Projekt ausprobieren.