Die IP-Adresse eines Clients stellt für Web-APIs einen wichtigen Datenpunkt dar. Sie wird für Anwendungsfälle wie der Personalisierung von Diensten, Protokollierungen und auch für Sicherheitsaspekte wie z.B. Rate Limiting benötigt. In diesem Artikel soll es daher darum gehen, wie sich die tatsächliche IP-Adresse eines Clients in einer Spring Boot Anwendung zuverlässig und sicher ermitteln lässt.

Um eine Anwendung vor unliebsamen Traffic wie Spam oder andere Formen von automatisierten Requests zu schützen, können Rate Limits genutzt werden. In diesem Artikel beschreibe ich, wie sich Rate Limits pro IP-Adresse in einer Spring Boot Anwendung umsetzen lassen.

Die W-JAX 2024 findet vom 4. bis 8. November 2024 in München statt. Das trion-Team ist vor Ort und bietet eine Vielzahl von Vorträgen sowie eine interaktive Night-Session an. Diese Formate ermöglichen es den Teilnehmenden, tief in technologische und architektonische Themen einzutauchen und anregende Diskussionen zu führen.

In einem vorherigen Artikel haben wir uns damit befasst, wie man Keycloak Rollen als Spring Security Authorities verfügbar macht, wenn Spring Boot als Resource Server agiert. In diesem Folgebeitrag betrachten wir nun den Fall, in dem unsere Spring Boot Anwendung die Rolle eines OAuth 2.0 Client einnimmt und einen OAuth 2.0 Login mit Keycloak implementiert. Auch hier wollen wir die Rollen aus Keycloak korrekt mappen.

Spring Framework 6.2 bzw. Spring Boot 3.4 bringt eine interessante Neuerung für Entwickler, die ihre Unit- und Integrationstests mit AssertJ schreiben: MockMvc Tests können nun auch mit AssertJ formuliert werden (GitHub Issue). Bisher musste für Controller-Tests mit MockMvc auf die Hamcrest-Syntax zurückgegriffen werden, was zu uneinheitlichen Test-Code führen konnte. Mit dem Release von Spring Boot 3.4 im November 2024 kann die vertraute AssertJ assertThat() API auch in Verbindung mit MockMvc verwendet werden, was das Testen von Web-Controllern eleganter und konsistenter macht. In diesem Artikel zeigen wir, welche Anpassungen am Code notwendig sind, um diese neue Möglichkeit nutzen zu können.

Dokumentation ist ein Thema, dass gerne hinten angestellt wird.
Quasi "wenn noch Zeit ist". Vergleichbar mit Tests wird Dokumentation von manchen Personen als schlecht investierte Zeit angesehen. Erschwerend kommt hinzu, dass die Pflege aufwendig ist: Wird die Software weiterentwickelt, so müssen oft auch Tests und Dokumentation nachgezogen werden.

Wir haben gute Erfahrungen damit gemacht, Dokumentation - wo möglich - zu generieren. Dabei kann sowohl der Java Quellcode als Quelle dienen, als auch Ergebnisse von automatisiert ausgeführten Tests.
Auf diese Weise kann die Dokumentation nah am Quellcode mitgepflegt werden, die Wahrscheinlichkeit sinkt, dass dies nicht bedacht oder vergessen wird.

In diesem Beitrag geht es darum, auch die Dokumentation der verwendeten Datenbankschemata zu dokumentieren. Dazu werden die Werkzeuge Testcontainers, Schemacrawler und JUnit miteinander verknüpft.

In vielen modernen Anwendungen nutzen wir Keycloak zur Authentifizierung für den Zugriff auf Spring Boot Anwendungen. Dabei werden Benutzer und ihre Rollen in Keycloak gespeichert bzw. von Keycloak bereitgestellt. In einer Spring-Anwendung möchten wir diese Rollen nun nutzen, um den Zugriff auf Ressourcen zu autorisieren. In einem weiteren Blogpost betrachten wir Fall in dem unsere Anwendung als OAuth 2.0 Client agiert und einen OAuth 2.0 Login implementiert.

Fullstack in modern - von Offlinefähigkeit bis hin zu Echtzeitanwendungen. Gemeinsam mit dem Java Magazin haben wir einen Artikelschwerpunkt entwickelt, in dem wir im Rahmen einer Beispielanwendung einige der Technologien vorstellen, mit denen wir auch in Kundenprojekten Architekturanforderungen umsetzen.

Dabei nutzen wir für die Beispielanwendung MQTT als Messagingsystem um Events bis in das browserbasierte Frontend auf Basis von Angular als ein Kommunikationsweg nutzen.

Als Sonderdruck ist der Schwerpunkt im PDF Format als Download am Ende von diesem Beitrag zu finden.

Mit Spring Security können unter anderem Webanwendungen (Spring WebMVC) auf einfache und flexible Weise abgesichert werden. Dabei ist der typische Weg über Security-Filter-Chains die Webschicht von Spring WebMVC mit Spring Security abzusichern. Doch reicht das aus?
Diese rhetorische Frage lässt sich mit vielleicht beantworten: Gibt es keine Programmierfehler oder Logikfehler, so kann das bereits ausreichen. Denn erreicht kein Request unberechtigt die Controller-Schicht, dann kann nichts passieren.

Doch in Zeiten zunehmender Cyberbedrohungen sollte keine Anwendung lediglich durch eine Schicht gesichert werden. Verteidigung in der Tiefe kann dank Spring Security leichtgewichtig mit Method Security umsetzen. Eine deutliche Verbesserung.

In unserem letzten Spring Security Training kam die Frage auf, wie sich dies mit periodischen Aufgaben innerhalb der Spring Anwendung kombinieren lässt. Das soll als Anlass dienen, sowohl periodische als auch asynchrone Ausführung, z.B. durch Message-Queue Nachrichten in Kombination mit Method Security darzustellen.

Die JAX 2024 steht vor der Tür und das Team von trion ist bereits in den Startlöchern, um Wissen und Erfahrung zu teilen. Mit einer breiten Palette von Vorträgen und einem interaktiven Night-Session-Format bietet trion Teilnehmern die Möglichkeit, sowohl in Bezug auf Technologie als auch Architektur in spannende Bereiche einzutauchen und tiefgehende Diskussionen zu führen.

Drools ist eine Rule-Engine, also ein Baustein für Expertensysteme und zur Flexibilisierung von Entscheidungen. Dabei ist Drools flexibel in bestehende JavaEE, Spring Boot und andere Frameworks integrierbar.
Dieser Beitrag beschäftigt sich mit folgender Fragestellung: Wie könnte eine Cloud-native Umsetzung von Drools im Gegensatz zu dem klassischen Modell einer Einbettung aussehen?