Open Source für verbindliche Klicks: CiviVerify für CiviCRM

Ich freue mich, dass wir mit CiviVerify eine erste, noch frühe Version einer CiviCRM-Erweiterung unter der freien AGPL-3.0-or-later-Lizenz veröffentlichen können.

Entstanden ist sie aus den Anforderungen an einen dreistufigen Bestellprozess mit Identitätsverifizierung der E-Mail-Adresse. Dabei sollte nachvollziehbar bleiben, welche Person wann welchen Vorgang bestätigt hat – ohne die fachlichen Abläufe fest in die Erweiterung einzubauen.

Daraus entstand die Idee für eine Erweiterung, die losgelöst vom konkreten Anwendungsfall generisch in CiviCRM für Kontakte und Entitäten funktioniert.

CiviVerify ist das Ergebnis, welches einmalige, zeitlich begrenzte Verifikationslinks bereitstellt. Ein Token kann an einen Kontakt und wahlweise an jede APIv4-Entität gehängt werden, etwa an einen Fall, eine Anmeldung oder einen eigenen Datensatz. So bleibt der Nachweis genau dort verankert, wo er fachlich hingehört.

Die wichtigsten Eckdaten:

  • Einmalige, zeitlich befristete Verifikationslinks
  • Bindung an Kontakte und beliebige APIv4-Entitäten
  • Tokens für Message-Templates, etwa für Bestätigungslink, Zweck, Ablaufzeit, UUID sowie Name und ID der gebundenen Entität
  • Symfony-Events bei Ausstellung, Bestätigung, Widerruf und Ablauf
  • Optionale CiviRules-Trigger und eine Aktion zum Ausstellen und Versenden
  • Eingebauter, zeitlich frei planbarer CiviCRM-Job: Er markiert abgelaufene Token als ungültig, löst das Ablauf-Event aus und bereinigt ältere, abgeschlossene Nachweise nach der konfigurierten Aufbewahrungsdauer
  • Scanner-sicherer Ablauf: Erst eine ausdrückliche Bestätigung per POST löst den Link ein
  • Roh-Token werden nicht in der Datenbank gespeichert
  • Fachliche Folgeaktionen bleiben bewusst bei den jeweiligen Fach-Erweiterungen oder CiviRules

CiviVerify ist als eine erste Alpha-Version verfügbar. Ich freue mich über Tests, Rückmeldungen und Beiträge: github.com/polbeo-de/civiverify

3 „Gefällt mir“

Cooer Anwendungsfall für eine neue Extension.

Ich wollte bei der Gelegenheit darauf hinweisen, dass der FormBuilder inzwischen alle Entity IDs über das JWT verschlüsseln kann, nicht nur ContactIDs – ist aber schlecht oder gar nicht dokumentiert(?). Das bedeutet, etwas ähnliches wäre auch von Haus aus mit dem FormBuilder realisierbar, wenn auch mit möglicherweise etwas mehr Konfigurationsaufwand.

Außerdem wär es echt cool zu markieren, wenn KI einen nennenswerten Beitrag zu Code beigetragen hat. Wir arbeiten auch mit KI wenns ums Coden geht aber fürs reviewen ist das gut zu wissen.

1 „Gefällt mir“

Hi Benn,

lieben Dank für den Kommentar und guter Hinweis zum FormBuilder. Für einen klassischen, formulargebundenen Prozess passt der auch prima.

CiviVerify ist jedoch keine direkte Konkurrenz dazu, sondern es ist eine kleine, leichtgewichtige und koexistierende Extension, die eine einzige Aufgabe hat: einen einmaligen, zeitlich begrenzten Nachweis bereitzustellen, der an Kontakt oder Entität gebunden sein kann – ohne selbst ein Formular oder eine bestimmte Folgeaktion/Folgelogik mitzubringen.

Der Unterschied liegt primär im Vertrag: Ein CiviVerify-Token ist ein Einmalschlüssel mit Ablauf, Widerruf und nachvollziehbarem Lebenszyklus. Bei Ausstellung, Bestätigung, Widerruf und Ablauf gibt es Ereignisse, auf die z. B. Deine Implementierung, CiviRules oder eine andere CiviCRM-Komponente reagieren kann. Die Zustellung läuft über eine transaktionale Outbox, damit ein bestätigter Vorgang nicht verloren geht, sollte das System crashen.

Das war mir wichtig, denn als ich überlegte, wie ich meinen konkreten Usecase wohl in CiviCRM umsetzen könnte, war auch Maschine-zu-Maschine-Austausch ein Kriterium: Ein Dienst kann über die regulär abgesicherte CiviCRM-API einen Token ausstellen oder prüfen und auf die (Lifecycle-)Ereignisse reagieren. Entsprechend ist ein Link die natürlichste Form für „echte“ Menschen; API4-Vodoo für das Blech. CiviVerify ist deshalb, nochmals ausdrücklich betont, keine Konkurrenz zum FormBuilder und auch kein Ersatz für OAuth oder Ähnliches. Für eine kryptografisch abgesicherte Verifikation mit einem nicht erratbaren Geheimnis hingegen schon.

Zum KI-Hinweis: völlig berechtigt. Ich komme als Informatiker aus der Java-Welt und über meinen Förderkreis zu CiviCRM buchstäblich wie die Jungfrau zum Kinde. PHP kann ich lesen und verstehen, aber die KI spielt hier den um Magnituden schnelleren Code-Monkey, sodass sie ohne Zweifel nennenswert an der Extension mitgewirkt hat. Dies ist für mich jedoch kein Makel: Architektur, Sicherheitsentscheidungen, Wahl des/der kryptografischen Verfahren(s), Reviews und die Tests liegen bei mir (mittlerweile uns, da eine Unternehmung draus wurde). KI ist für mich ein weiteres Tool in meinem Werkzeugkasten, das ich dank Ausbildung und Erfahrung hinreichend beherrschen kann. Es bringt mich heute meist schneller ans Ziel und ich nehme wahr, dass es muntere Diskussionen, teils ideologisch und weniger fachlich geprägt, zu diesem Thema gibt.

Beim Lesen dieses Artikels ertappte ich mich öfter beim zustimmenden Nicken, mag auch an der Ü50 liegen ;). Ex-GitHub-Chef im Interview: Über den Unterschied zwischen Vibecoding und Pfusch | heise online (heise Geschenklink)

Dies gesagt, nehme ich gleichzeitig gerne mit, diese Unterstützung im Repository künftig deutlicher zu dokumentieren, sodass Menschen wie Du und automatisierte Agenten schneller zum Ziel kommen.

\Fabian

PS

Jetzt wurde es doch ein halber Vorstellungstext, ich glaube, ich werde ihn einfach crossposten und um Familie, meinen Faible für Snowboarden und Schweden ergänzen. :winking_face_with_tongue:

3 „Gefällt mir“

Danke für die Einordnung! Jetzt verstehe ich besser, was eure Extension noch so leistet und das klingt echt nice, insb. die lifecycle-events und api-integration.

Für mich als nicht-Programmierer ist KI auch ein super hilfreiches und alltägliches Tool geworden. Mir ging es wirklich nur um die Kennzeichnung. :smiley:

1 „Gefällt mir“

Gerne, die Extension wandert jetzt auch in den offiziellen Katalog ( CiviVerify | CiviCRM ) dort gibt es auch ein paar Screenshots zur Verwaltungsoberfläche, die ich bei github im Readme unpassend finde. Ich würde mich jedenfalls freuen, wenn sie auch in anderen Projekten erfolgreich zum Einsatz kommt.

\Fabian

1 „Gefällt mir“

Das scheint für uns interessant zu sein. Wir setzen bei Self Services auf Magic Links. Das scheint mir dafür geeignet zu sein.