Skip to content

JWK Validator: Cache Speicherung

Warum?

  • Mit dem Ticket #453 (closed) (#453 (closed)) hat FIT-Connect die Möglichkeit erhalten, schnell zu agieren, da nicht bei jedem Zertifikatsabruf eine direkte online Gesamtprüfung der Sperr- als auch Zertifikatslisten durchgeführt werden muss.
  • Als zweiter Schritt beschäftigt sich dieses Ticket damit, dass FIT-Connect noch autonomer wird, indem nicht täglich eine online Abfrage der Sperr- und Zertifikatslisten durchgeführt werden soll. Stattdessen soll der Cache gespeichert werden. Die Vorteile sind, dass wir autonomer von der Telekom werden und zugleich beständig in unserer Qualität bleiben, da wir weiterhin die neusten Listen, nach ihren jeweiligen wöchentlichen Veröffentlichungen, abrufen.

Relevante Links und Bemerkungen

Akzeptanzkriterien

  1. Es wurde mit Team Infrastruktur abgesprochen wo und wie der Cache abgelegt werden kann
    1. Ablage des Offline-Caches per Ordnerpfad
    2. Ablage des Offline-Caches per S3
  2. Die Nutzung eines Offline-Caches wird über einen Parameter im Builder kontrolliert
  3. Zugriffszeiten auf Cache-Werte dürfen nicht länger werden
  4. Änderungen am Offline-Cache durch Dritte zwischen Neustarts sollten erkannt werden (hängt etwas davon ab, was von Punkt 1 zurückkommt)
  5. Wenn möglich, sollte auch bei einem Ausfall und dem darauf folgendem Neustart ein Offline-Cache vorliegen
  6. Offline-Cache wird nach dem Konfigurieren via Builder geladen und von veralteten Einträgen bereinigt
  7. Wenn ein Offline-Cache vorliegt, der JWK-Validator aber ohne Offline-Cache konfiguriert wurde, wird dieser gelöscht
  8. Der Offline-Cache wird vom JWK-Validator genutzt, um den eigentlichen RAM-Cache zu befüllen
  9. Der Offline-Cache ist ein optionales, konfigurierbares Zusatzfeature; der bestehende RAM-Cache bleibt in seiner jetzigen Funktionalität bestehen.

Durchführungsplan (von Entwickler:in bei Umsetzungsplanung auszufüllen)

Edited by Michael Miera