Bester Weg zu einem Wordpress Internbereich mit CT Login-Daten

Silas K.

Wir wollen einen Internbereich mit Churchtools Logindaten in eine Wordpress Webseite bauen. Wir sehen drei mögliche Wege zur Verbindung von Webseite und Churchtools und fragen uns, welche der Beste ist und ob bestimmte Wege unsicher oder dumm sind.

1. LDAP
Als erstes könnte man (z.B. mit einem Plugin) den LDAP Server von Churchtools kontaktieren und dann die Nutzer von Wordpress mit den Nutzern von Churchtools syncronisieren. Wenn wir das richtig verstehen würden dann aber die Passwörter oder sogar das Passwort eines Admin Users von Chruchtools in der Datenbank der Webseite gespeichert werden, was uns riskant scheint.

2. Serverseitig (PHP) die Rest API ansprechen
Der Nutzer gibt seine Logindaten in ein HTML Form ein, das auf eine PHP-Action zielt. Der Webserver fragt dann die REST API an (per php) und bekommt im erfolgreichen Login-Fall einen Cookie und einen Login-Token zurück. Diesen würde er dann einfach an den Nutzer (Browser/Client) weiterleiten. Bei jedem neuen Seitenaufruf kann dann per php geschaut werden (als neues Aufruf an die API z.b. /whoami mit Cookie), ob der Nutzer eingeloggt ist, bzw. welchen Status er hat. Der Vorteil hier wäre, dass nichts auf dem Server gespeichert werden muss. Der Nachteil, dass es sich falsch anfühlt den Cookie und den Login-Token an den Client durchzureichen, obwohl diese ja für den Server angefragt wurden - oder ist das so gedacht?

3. Clientseitig (JS) die Rest API ansprechen
Der Nutzer gibt seine Logindaten in ein HTML Form. Beim Absenden wird per Javascript ein request an die Rest API "/login"-Schnittstelle geschickt. Wenn er erfolgreich war, speichert der Client den Login-Token und den Cookie in seinem Browser. Das Schöne wäre hier, dass man den Server quasi gar nicht braucht. Das Problem wäre dass der Server nicht weiß, ob der Nutzer bei CT eingeloggt ist (in php). Man kann also von der Wordpress Seite nicht bestimmte Seite nur dann zur Verfügung stellen, wenn man eingeloggt ist und z.B. einen bestimmten Status hat. Hinzukommt, dass man CORS für die entsprechende Domain erst vom Support freischalten lassen muss, was möglich aber auch kein Pluspunkt ist.

Ist das so vom Grundverständnis überhaupt richtig?
Gibt es Lösungen die sinnvoller als andere für unseren Anwendungsfall sind?
Gibt es noch andere Wege, als die hier besprochenen?

Liebe Grüße und großes Danke für eure Arbeit!
Silas

David.R

Ich wartete darauf schon sehr lange. War vor Jahren mal von CT angedacht, dass es da eine Verknüpfung geben sollte.

Ich bin einen anderen Weg gegangen. WP braucht bei uns faktisch kein internen Bereich mehr, da alles über CT abgebildet wurde was wir da hatten. (Hauptsächlich Downloads etc.)

So habe ich in WP nur noch die Seitenbearbeiter drin mit Zugang und Passwörter.

MichaelG

@silas-k Hi Silas, jetzt weiß ich nicht genau, für welches Szenario du das fragst, aber wäre das unser Projekt, kämen noch das Problem hinzu, dass du so nur Personen abgreifst, die bereits einen Login über CT haben.
Wenn nun auch Personen über WordPress sehen können sollen, ob sie in einer bestimmten Gruppe sind etc. aber noch keinen CT-Login haben, scheinen diese auch keine Möglichkeit zu haben, sich in WordPress einzuloggen.
Aber gerade die, die nicht in CT können, hätten den Mehrwert über WordPress zu gehen.

Im Endeffekt müsste WordPress dann einen Abgleich machen, ob die Person bereits einen CT-Login hat. Wenn nicht, muss die Person die registrieren (in einer Art wird eine Kontaktkarte ausgefüllt) und dadurch dein zuerst abgeglichen, ob ein Datensatz zu der Person existiert.

Falls ja, wird diesem Datensatz ein CT-Login erstellt.

Falls nein, wird dieser Datensatz angelegt und dann ein CT-Login erstellt.

Silas K.

@michaelg Hi Michael,

ich denke es gibt generell zwei Nutzerfälle in denen einen Anbindung an die Webseite sinn macht:

Churchtools nur im Hintergrund. Die Wichtigkeit von Branding wird immer mehr Gemeinden bewusst. Das was sie ihren Mitgliedern und Gästen anbieten, ist ein Angebot ihrer Gemeinde. Churchtools ist ein super Verwaltungstool, um das keine Gemeinde in der Zukunft mehr herumkommen wird, aber es hat ungefähr die Tonalität meiner Versicherung. Ich kann aber weder die Tonlität meiner CT Instanz ändern, noch kann ich generell eine eigene gebrandete Version nutzen. Nun kann es sein, dass eine Gemeinde sich mit Churchtools organisiert und vielleicht auch die leitenden Mitarbeiter Churchtools als Software nutzen. Dem Gemeindemitglied und Freund der Gemeinde möchte man aber keine Verwaltungssoftware anbieten, sondern ein fancy internbereich im eigenen Branding in dem vielleicht auch nur teile der Churchtools Features abgebildet sind. Ähnlich verhält es sich, wenn eine Gemeinde eine eigene App haben möchte die CT als teilweises Backend nutzt. Szenario eins ist also, dass Churchtools für eine gewisse Nutzergruppe nur im Hintergrund operieren soll und man eine gebrandete Alternative möchte.
Chuchtools erweitern. Man kann Churchtools nicht durch Plugins oder ähnliches erweitern. Selbst wenn man eine eigene selbstgehostete Instanz hat, hat man keinen Einfluss auf die App. Man stelle sich vor man hat eine eigene kleine E-Learning Plattform oder andere Inhalte wie z.B. ein schwarzes Brett auf der Webseite, dass für Mitglieder zur Verfügung stehen soll. Wann immer ich eine Funktion haben möchte, die Churchtools nicht anbietet wäre es häufig am einfachsten das auf der eigenen Webseite anzubieten und dann aber die gleichen Logindaten zu nutzen. Noch besser wäre es natürlich wenn es in Zukunft irgendeine Art Plugin Lösung geben würde.

Zu den Nutzern ohne CT-Account: In der API habe ich keinen Endpunkt gefunden, über den sich neue Nutzer registrieren könnte, aber vielleicht ist der natürlich auch nur noch nicht dokumentiert.

Meine Frage war ja eigentlich noch mehr, welcher der oben beschriebenen technisch beste Weg wäre.

skipy

@silas-k
Hallo Silas,
nach einigem Schwanger-Gehen würde ich persönlich die PHP via REST-API Variante verwenden.

zu 1. LDAP

Passwörter synchronisieren gefällt mir auch nicht
Wenn ihr (was du unten schreibst) weitere Informationen aus ChurchTools auslesen und über eine eigene Homepage mit CT interagieren möchtet, kommt ihr dann sowieso nicht um die API rum.
Via LDAP könntest du auch ohne Synchronisieren arbeiten (denke ich). Also lediglich die Authentifizierung prüfen und wenn das passt, wird der Nutzer in Wordpress mit einer Session eingeloggt.

Zu 2. PHP / API

das geht technisch denke ich am einfachsten
Ähnlich wie du es beschreibst: Der Nutzer gibt seine CT-Zugangsdaten in ein Login-Formular ein. Via PHP werden diese gegen die ChurchTools API geprüft und validiert. Wenn alles passt, wird der Nutzer (falls noch nicht geschehen) in Wordpress angelegt und eingeloggt. Die Login-Session für Wordpress übernimmt den Rest, so dass keine dauerhafte Verbindung zur Churchtools-Installation offengehalten werden muss. Solltest du darüberhinaus noch weitere Interaktionen mit der API planen, würde ich beim Login auch noch ein ChurchTools Token generieren und dieses in Wordpress als Benutzer-Attribut für später abspeichern.
Vielleicht hilft dir als Anhaltspunkt
- zur API: https://packagist.org/packages/stevenbuehner/sb-churchtools-api
- zum Login schau dich hier mal um: https://developer.wordpress.org/reference/functions/wp_authenticate/

Zu 3. JS

Finde ich super attraktiv, weil bereits in CT eingeloggte Nutzer direkt auch in Wordpress eingeloggt wären
Aber leider konnte ich (abgesehen von CSRF) keine Tokens oder Login-Informationen erkennen, welche du direkt verwenden könntest.
In der API v1 gibt es eine Möglichkeit, wie du nach dem Login einen neuen Token generierst, den könntest du dann an Wordpress übergeben. Das generiert aber bei ChurchTools intern einen separaten Logineintrag und könnte (weil es per JS ausgehandelt werden müsste) ein potentielles Sicherheitsrisiko darstellen.
Dokumentiert ist von Seitens ChurchTools meines Wissens hierzu nichts.

Ich persönlich würde die PHP Variante wählen ... geht am schnellsten, ist flexibel und zukunftssicher.

DumbergerL

Hi @Silas-K,

ich kann mich @skipy nur anschließen. Die REST-API serverseitig in PHP zu verwenden macht aus meiner Sicht am meisten Sinn.

Wir nutzen das gleiche Prinzip, zwar nicht mit Wordpress, aber mit einer Laravel Webanwendung und es funktioniert ohne Probleme. Wir nutzen dafür diesen API Wrapper:

Damit lässt sich der Login super einfach durchführen:

CTConfig::setApiUrl($ctUrl);
CTConfig::authWithCredentials($email, $password);
$apiKey = CTConfig::getApiKey();

Du kannst auch einen in der DB gespeicherten API-Key auf seine Gültigkeit prüfen:

CTConfig::setApiKey($apiKey);
if(!CTConfig::validateApiKey()){
    // show user login form
}

Ich hoffe das hilft dir ein bisschen weiter.

bwl21

@dumbergerl Hi, dein API-Wrapper sieht wirklich gut aus. Du hast ein konsistentes Konzept von Requests und Models (mit query). Das gefällt mir.

Ich verfolge den Ansatz von @fodinabor (in einem Fork https://github.com/bwl21/CT-API-Tools/tree/develop) welcher das API direkt nutzt und nur helper, aber keine Wrapper bereitstellt.

Silas K.

@dumbergerl @skipy @MichaelG
Danke euch allen für eure Antworten, das hat auf jeden Fall geholfen. Danke auch @DumbergerL für deinen Wrapper, den hatte ich beim Googlen nicht gefunden, der sieht ja aber super aus. Ich denke den werden wir nutzen.