[SSP] Anbindung React-SPA an bestehendes Backend [L]

Release-Version: SSP 1.5.0

Warum?

Das in #435 (closed) erstellte neue Frontend, soll an das bestehende SSP-Backend angebunden werden.

Relevante Links und Bemerkungen

Die Übermittlung an das SSP-Backend kann pragmatisch über ein verstecktes <input>-Element an das Backend übermittelt werden:

<input type="hidden" name="destination" value="{\"contactInformation\":{ ... },\"services\":[ ... ],...}"> 

Akzeptanzkriterien

1. Die React-SPA kann sich über die im aktuellen SSP existierenden Sessions (Session-Cookie) gegenüber dem Backend authentifizieren.
2. Die Übermittlung an das SSP-Backend erfolgt über ein verstecktes <input>-Element.
3. Die bisherigen Formularkomponenten werden sowohl im Frontend (Thymeleaf), als auch im Backend (Spring) gelöscht.
4. Vor Aufruf der Submission API wird das Destination-Objekt im SSP-Backend gegen das JSON-Schema gemäß Submision API validiert. weggefallen
5. Alle bestehenden Fehlermeldungen bleiben erhalten (oder werden verbessert).
6. Bei der Anlage und Verwaltung von Zustellpunkten werden bei auftretenden Fehlern aussagekräftige Felermeldungen mit (verlinktem) Lösungsansatz angezeigt. Dies beinhaltelt mindestens die folgenden Punkte (Hinweis: Eine Prüfung der muss nicht zwingend direkt im SSP erfolgen, sondern könnte, wenn sinnvoll, ggf. auch anhand der Rückmeldung der Submission API erfolgen):
   • Eingaben entsprechen nicht den in der API definierten Constraints (Wert zu kurz/zu lang, Wert entspricht nicht dem in der API definierten Pattern) -> Dies kann durch die Schema-Prüfung im Backend und/oder durch Prüfung via JS erfolgen. Wichtig ist hier eine aussagekräftige Fehlermeldung.
   • Kryptographische Vorgaben sind nicht eingehalten (z.B. Schlüssellänge, Algorithmen - siehe #119 (closed) und #302 (closed)) -> Hier ist vermutlich eine Implementierung im SSP-Backend aufgrund der nötigen Fehlerbehandlung einfacher. Wichtig sind auch hier aussagekräftige Fehlermeldungen im Frontend.
   • In der Produktivumgebung: Verschlüsselungs- und Signaturschlüssel beinhalten kein gültiges Zertifikat aus der V-PKI -> Diese Prüfung kann anhand der Rückmeldung der Submission API erfolgen. -> Wird behandelt in #575 (closed)
7. Bestehende Mechaniken zur Vermeidung von Cross-Site-Scripting (XSS) bleiben erhalten oder werden ergänzt.

Durchführungsplan (vom Entwickler bei Storyplanung auszufüllen)

• AK 6: Bei diesem Bereich geht es hauptsächlich um die Ausgabe sinnvoller Fehlermeldung. Diese Bereiche sollen intensiv überprüft werden.
• Kompliziertere Fehlerfälle prüfen und z.b. im Falle eines ungültigen JWK's auf die Dokumentation für diese Bereich verweisen
• Pro Datenbereich in dem ein Fehler auftritt, soll die jeweilig passende Dokumentation verlinkt werden
• Definition of Done wurde geprüft
• Schemaprüfung im Backend implementieren, falls das mit wenig Aufwand möglich ist. Diese Prüfung existiert im Frontend bereits.