Schema-Prüfung vor der Prüfung der `authenticationTags` des `accept-submission`-Events

Als Fachverfahrenshersteller

möchte ich nicht, dass - ohne Vorwarnung - auf meiner Seite erzeugte accept-submission-Events nicht mehr entgegengenommen werden.

Why

Mit #317 (closed) wurde eine Prüfung umgesetzt, die sicherstellt, dass die authenticationTags aus dem accept-submission-Event den authenticationTags des submit-submission-Events entsprechen.

Beim Testen der Umsetzung von #317 (closed) auf der DEV-Umgebung und bei Analysen auf höheren Umgebungen wurde festgestellt, dass es aktuell zu der Konstellation kommen kann, dass nicht valide accept-submission-Events beim zustelldienst ankommen. In der speziellen Konstellation kommt es durch eine fehlende Schema Angabe in dem Event dazu, dass keine Schema-Validierung stattfindet und das invalide Event erfolgreich entgegengenommen wird. Mit planning#1444 und #1445 (closed) soll das Schema zwingend erforderlich sein und damit auch eine Schema-Validierung jedes accept-submission-Events erfolgen.

Es muss zunächst sichergestellt werden, dass alle Anwendungen das schema zwingend mit angeben. Dieses Schema soll mit planning#1444 und #1445 (closed) zwingend erforderlich sein. Bis diese beiden Issues umgesetzt sind, wird es vermutlich weiterhin Anwendungen geben, die - wie bisher - nicht valide Events an den zustelldienst schicken.

SOLL

Daher soll die folgende temporäre Prüfung zusätzlich stattfinden, bis planning#1444 und #1445 (closed) umgesetzt sind: Die mit #317 (closed) eingeführte Prüfung soll nur dann angewendet werden, wenn ein valides Schema angegeben ist und damit eine Schema Validierung statt gefunden hat.

Links, Notes, Remarks

Kommentar aus #317 (closed) der den Sachverhalt und die Lösungsidee beschreibt:

• Szenario 1: Es wird über POST /v1/cases/<ID>/events ein accept-submission Event versendet. Dieses Event enthält keine payload ({} → invalide) und es ist keine Schema Version (was aktuell noch nicht enforced ist, siehe planning#1444) angegeben. Verhalten: Da kein Schema angegeben ist, kann keine Schema-Validierung gegen das Schema stattfinden. Mit der aktuellen Umsetzung von diesem Issue (#317 (closed)) werden dennoch beim Verarbeiten des Events authenticationTags erwartet, um sie mit den authenticationTags des submit-submission Events zu vergleichen. Da diese nicht vorhanden sind, ist der Abgleich nicht möglich und es wird ein HTTP Status Code 422 zurück gegeben und das Event wird somit nicht angenommen. Das beschrieben Szenario 1 ist auch in diesem API Test entsprechend umgesetzt und dokumentiert.
• Szenario 2: Es wird wieder über POST /v1/cases/<ID>/events ein accept-submission Event versendet. Auch dieses Mal enthält das Event keine payload ({} → invalide), ABER dieses Mal ist ein Schema angegeben. Verhalten: Durch das angegebene Schema findet eine Schame-Validierung statt. Im Zuge dieser Validierung wird festgestellt, dass die authenticationTags in dem Event fehlen. Daraufhin wird ein Http Status Code 422 zurückgegeben, mit dem Hinweis [...] "Missing property authenticationTags". Auch das beschriebene Verhalten des 2. Szenario ist in einem API Test festgehalten.

Wie heute morgen vermutet gibt es aktuell auf den höheren Umgebungen Anwendungen, die uns weiterhin keine validen accept-submission Events senden und kein Schema angeben. Dieses Schema soll mit planning#1444 und #1445 (closed) zwingend erforderlich sein. Bis diese beiden Issues umgesetzt sind, wird es vermutlich weiterhin Anwendungen geben, die - wie bisher - nicht valide Events an den zustelldienst schicken. Diese Events würden durch die aktuelle Umsetzung von #317 (closed) jedoch nicht mehr vom zustelldienst angenommen. Daher könnte eine temporäre Anpassung sein, dass, bis planning#1444 und #1445 (closed) umgesetzt ist, die mit #317 (closed) eingeführte Prüfung nur dann angewendet wird, wenn ein valides Schema angegeben ist und damit eine Schema Validierung statt gefunden hat. Damit haben Anbindungsprojekte Zeit, die Eventerstellung an das Schema anzupassen. Die letztgenannte Prüfung nach dem Schema müsste dann als direktes Follow-Up auf #317 (closed) erfolgen und nur gemeinsam mit diesem Issue auf den höheren Umgebungen eingespielt werden.

Acceptance criteria

1. Es gibt einen API-Test der prüft, dass beim Erstellen eines accept-submission-Events ein Fehler zurückgegeben wird, wenn ein konkretes Schema angegeben ist, aber die authenticationTags fehlen.
2. Es gibt einen API-Test der prüft, dass beim Erstellen eines accept-submission-Events KEIN Fehler zurückgegeben wird, wenn KEIN konkretes Schema angegeben ist und die authenticationTags fehlen (temporäres Verhalten, bis planning#1444 und #1445 (closed) umgesetzt sind.
3. Es gibt einen API-Test der prüft, dass beim Erstellen eines accept-submission-Events KEIN Fehler zurückgegeben wird, wenn ein konkretes Schema angegeben ist und die authenticationTags mit den Tags aus dem submit-submission-Event übereinstimmen.
4. Es gibt einen API-Test der prüft, dass beim Erstellen eines accept-submission-Events ein Fehler zurückgegeben wird, wenn ein konkretes Schema angegeben ist, aber die authenticationTags mit den Tags aus dem submit-submission-Event NICHT übereinstimmen.

Implementation plan (to be completed by the developer)

• ...
• ...
• ...