Genau. Die Payload könnte er beliebig modifizieren. Allerdings passt dann die Signatur nicht mehr zum Inhalt (Header+Payload). Wenn das modifizierte Token dann ans Zielsystem geschickt wird, schlägt die Validierung der Signatur fehl. Die Signatur könnte man natürlich auch ersetzen. Um das korrekt zu machen, müsste der Mitarbeiter dann allerdings das Geheimnis kennen. - Und das tut er hoffentlich nicht. (Der Fall 'Geheimnis erraten' wird ja auch im Video diskutiert. Geht natürlich auch. Allerdings werden bei guten Geheimnissen sehr sehr sehr sehr viele Rateversuche benötigt, sodass dieser Angriff eher theoretischer Natur ist.) Wenn man Sorge hat, ob die Signatur am Zielsystem korrekt validiert wird (zum Beispiel, weil es sehr sehr viele Zielsysteme gibt), empfiehlt es sich, ein API Gateway vor das Zielsystem zu hängen. Alle HTTP Requests müssen dann durch den durch, bevor sie ans Zielsystem dürfen. Im API Gateway kann man dann die Logik 'wenn Token am Request, validiere Signatur' realisieren. (Full Disclosure: Wir geben als open source Projekt Membrane API Gateway heraus: www.membrane-api.io/ )

Thanks for the comment. Hope the subtitles weren't to bad.

Danke für den Kommentar und das Feedback

Danke für den Erfahrungsbericht. Die Security Abteilung hat eine wichtige Rolle und liefert oft ein Framework, mit welchem Risiken und Massnahmen abgewogen werden können. Davon hängt dann ab, was im Einzelfall möglich ist.

Wie willst du ein Token fälschen wenn der signiert wird? Da müsste ja der Angriffsvektor bei dem "Token Service" sein.

Vielleicht stelle ich mir das zu einfach vor: Aber es gibt ja die Angriffe mit "geklauten" token - zumindest in der PHP-Welt. (Und ich sage auch nicht, dass hier ein Problem liegen MUSS - deswegen frage ich ja!).@@ragilo13

@@cgsman1 Meiner Meinung bzw Wissens nach besteht kein Problem, wenn der "Token Service" sauber implementiert ist. Kommt ja auch drauf an, welche Art von Tokens man verwendet. Alles hat wie immer Vor und Nachteile. Eine Sicherheitslücke in der Authentifizierung führt, aber quasi "immer" zu nem Desaster. Zumindest wenn man nicht On-Prem airgapped ist.

Danke für die Motivation

Danke für den Hinweis. Die API sollte verfügbar sein. Gab es eine Fehlermeldung oder ein Timeout?

Danke für den Hinweis. Die API sollte verfügbar sein. Gab es eine Fehlermeldung oder ein Timeout?

@@predic8 einen CORS Fehler für post delete und put anfragen get funktionierte

Ausserhalb vom Browser sollte es funktionieren. Im Browser eigentlich auch, da der "Access-Control-Allow-Origin: *"-Header gesetzt ist. In letzter Zeit gab es aber trotzdem Probleme im Browser. Vielleicht wurden die Anforderungen wieder verschärft. Ich schaue mir das Mal an.

Danke für den Hinweis. Ich werde das im nächsten Video berücksichtigen.

Danke für deinen Kommentar.

Hallo Marcom, danke für deine Kritik an Spring Modulith und die Diskussionspunkte. Ich frage mich auch, wo Java- oder Maven Module vielleicht besser passen. OSGi hätte noch eine Alternative sein können, die viele Probleme ganz gut gelöst hätte. Leider hat sich OSGi aber nicht so verbreitet. Das mit dem späteren Ausgliedern ist meiner Meinung nach mehr ein Argument als eine Eigenschaft.

@@thomas-bayer Hallo Thomas, ich habe vor ca. 3 Jahren mal an einem Spring-Boot-Projekt teilgenommen, wo wir für jeden Bounded Context zwei eigene Maven-Module erstellt haben: Eines für die Implementierung und eines für die öffentliche API. Jedes dieser Module hatte auch sein eigenes git-Repo. Java Modules waren damals nicht im Fokus, kann also nicht sagen, ob man den Ansatz sinnvoll nutzen könnte. Was wir aber gemacht haben: Jeder Bounded Context hatte seine eigene SubApplication mit eigenem Spring Context. Die Module wurden dann durch eine Spring Boot Application zusammengefasst. Kommunikation fand nur über die APIs statt, wobei die APIs letztlich aus Commands, Queries und Events bestanden. Ich denke Du verstehst, wohin die Reise da geht. Ist natürlich ein viel komplexeres Setup, aber gerade hier würde einem ein entsprechen vorgefertigtes "Modulith-Framework" viel Arbeit abnehmen könnnen.

​@@marcom. danke für die Beschreibung. Ich hoffe, dass Spring Modulith dazu beiträgt, dass mehr in Modularisierung investiert wird. Die Techniken dafür sind wie du beschreibst alle schon da. Die Maven-Module, SOLID-Prinzipien, Frameworks, ...

Danke für das Feedback. Grundsätzlich ist zu sagen, dass Spring Modulith keine Entweder-Oder-Alternative zu anderen Modulansätzen ist. Zum Einen ist das Featurespektrum von Spring Modulith *komplett* auf Applikationsentwickler zugeschnitten. Zum Anderen "fehlen" den von dir genannten Alternativen Features wie die Testintegration, die Dokumentation usw. völlig, und haben einen deutlich technischeren Fokus (JPMS: 1:1 Beziehung zwischen Modul & JAR usw.). Wichtig ist eigentlich zu erkennen, dass es eine Art "Werkzeugraum" gibt, in dem jedes Werkzeug unterschiedliche Tradeoffs eingeht und sich die Werkzeuge auch kombinieren lassen. Wenn man das Abhängigkeitsmanagement eher über Buildmodule realisieren möchte: bitte gern. Dann kann man immer noch die Dokumentations- und Integrationstestfeatures von Spring Modulith nutzen. Etwas herausgezoomt ist uns wichtig, den Blick für dieses Thema zu schaffen: wie bilde ich eine fachliche Architektur in einer Applikation ab. Der potentielle Umbau in ein später verteiltes System ist durchaus ein Thema für uns. Der gesamte Bereich der Unterstützung für Event-basierte Kommunikation bereitet genau das vor, weil man dadurch die Transaktionsklammern bereits auf einzelne Module begrenzt. Ist das erstmal in der Applikation etabliert, ist es recht einfach, ein Modul in eine separate App zu schieben und die Events z. B. über einen Kafka in die andere Applikation zu tragen. Das funktioniert in den Produktionsdeployments die wir aktuell sehen ziemlich gut. Ich weiß von Projekten, die nicht Spring Modulith verwenden, aber für jedes logische Modul einen separaten ApplicationContext starten. Das erfordert deutlich mehr technische Koordination und verbraucht deutlich mehr Ressourcen (EntityManager und Servletcontainer pro Kontext usw.) Ich sage nicht, dass das falsch ist. Es ist nur wieder ein anderer Tradeoff. Gut möglich, dass wir das irgendwann als advanced Feature auch mal anvisieren.

Hallo, danke für den Beitrag. Mit dem Abchecken der Voraussetzungen kannst du optimistic Locking realisieren und für mehr Konsistenz trotz HTTP Schnittstelle sorgen.

Danke Yasin für den Kommentar.

Hi Frederik, danke für die Beschreibung deines Ansatzes. Ich denke, dass das ganz praktikabel ist.

Hi @marcom, danke für die Hinweise. Datenzugriff und Transaktionssicherheit darf man in der Diskussion nicht vergessen. Den Modulith kann man in einem Repo entwickeln, wie du schreibst muss man das aber nicht. Man kann sogar aus mehreren Code-Repos entweder einen Modulith oder Microserives bauen.

no-cache wird wahrscheinlich an erster Stelle verwendet um garantiert eine frische Antwort, die nicht aus dem Cache kommt zu erhalten. Bei der Invalidierung für andere z.B. nach einem PUT ist man darauf angewiesen, dass der Client wirklich die Invalidierung durchführt. Was nicht einfach ist, wenn man selbst nicht den Client implementiert. Caches bieten natürlich auch eine Angriffsoberfläche. Man kann z.B. versuchen mit Cache Poisening eine Attacke zu fahren. Dabei wird z.B. nach einem HTTP-Header gesucht, der nicht in den Cache-Key eingeht, der aber einen Fehler verursacht, der dann gecached wird. Um den Cache für eine DOS zu umgehen, genügt es, den Cache-Key z.B. mit einem zusätzlichen Query-Parameter zu verändern. Es kann je nach Anforderung auch Sinn machen, den no-cache nicht zuzulassen.

@@thomas-bayer danke für die ausführliche Antwort. 😁. Bzgl. der GET Parameter sollte der Cache imho nur geprüfte Werte in den Cache ablegen. Ansonsten könnte man den Cache fluten bis er in die Knie geht. Bei Web Applikation kann man das lösen in dem man die Parameter signiert und GET Anfragen ohne Signatur verwirft. Aber bei einer API ist das natürlich deutlich aufwendiger. Vermutlich wäre da eine Whitelist mit erlaubten Parametern in Kombination mit einer Authentifizierung und Rate Limiter eine gute Option.

Danke für das Feedback. Ich werde weiter am Stil arbeiten.

Hallo Peter, wenn es geht bevorzuge ich immer eine statuslose Integration. Es läuft aber leider schnell auf eine eigene Datenhaltung heraus. Du must meist aber nicht allzuviel speichern. Bei aufsteigenden Ids, oder einem lastModified-Feld genügt oft nur ein Wert pro Datensatzart. Wenn es das nicht gibt, kannst du anstatt den gesamten Datensatz zu speichern einen Hash erzeugen und den abspeichern. Um die Änderungen zu bekommen, ziehst du alle Daten ab, bildest die Hashes und vergleichst diese. Auf den Bus schickst du dann nur die Datensätze, bei denen sich der Hash geändert hat.

Hallo, Thomas passt. Zu deiner Frage. Es kommt ganz auf die Aufgabe an. Manchmal bekommst du ein Schema, z.B. aus einer OpenAPI Datei. Für bestimmte Branchen gibt es auch Standards, die zunehmend ein JSON Format vorschreiben und ein dazu passendes JSON Schema mitliefern. Es kann auch sein, dass man selbst ein Format entwerfen muss. Für die Beschreibung des Formats kann dann JSON Schema ein Hilfsmittel sein. Das JSON Schema kann dann auch als Dokumention oder Vorlage für nachgeordnete Arbeiten dienen. Ich hoffe, dass das ein wenig zu Klarheit beitragen kann. Viel Erfolg und Spass beim vortasten.

Hallo Florian, mit Unfied Namespaces hatte ich bisher noch keine Berührung. Ich habe mir das Thema gerade kurz angesehen. Die Verteilung über MQTT und Pub/Sub ist im Prinzip die Alternative mit Messaging und Bus aus meinem Video. Danke für den Tip, Unified Namespaces werde ich weiter verfolgen.

Danke

Am besten immer nur das Offensichtliche dokumentieren, das spart Zeit und vermeidet Fehler 🙂. Ich stimme dir zu, dass der Kommentar keine neuen Informationen enthält und dass man das besser machen kann. Die redundante Info kann trotzdem nützlich sein, da man die commit-Nachrichten automatisch in die Release Notes übernehmen kann.