Cross-Site-Request-Forgery oder kurz CSRF ist ein Angriff, bei dem der Browser eines Nutzers auf einer böswilligen Webseite dazu veranlasst wird, einen Request gegen eine andere Webseite durchzuführen. Ist der Nutzer auf der Zielwebseite eingeloggt, sendet der Browser bei manchen Verfahren die notwendigen Informationen automatisch mit, sodass der Request ebenfalls authentifiziert erfolgt. Dadurch kann der Angreifer Aktionen im Namen des Nutzers ausführen.

Ein populärer CSRF Angriff ist z.B. der Facebook "like" Angriff, bei dem Nutzer unbeabsichtigt und unwissentlich "Like" für Inhalte abgaben. Dies führte zur Verbreitung von unerwünschten Inhalten und Manipulation des Rankings.

In diesem Beitrag wird der CSRF Angriff im Detail erläutert und in Kombination von Spring Security und einer Browser Anwendung auf Basis von Angular diskutiert, wie ein entsprechender Schutz implementiert werden kann.

Die Trion GmbH nimmt regelmäßig an der JAX-Konferenz teil, einer der größten Konferenzen für Java-Entwickler und IT-Profis in Europa. Auf der JAX und W-JAX präsentiert Trion seine neuesten Technologien und Lösungen, darunter auch Cloud-Lösungen...

Wie macht man mobile Entwicklung heute?
Häufig ist die Antwort hierfür ein Cross-Platform Framework. Insbesondere für Rapid Prototyping sollte der initiale Entwicklungsaufwand möglichst begrenzt sein. Wenn gleichzeitig auch die langfristigen Wartungskosten reduziert werden können, lassen sich diese Prototypen im nächsten Schritt gleich in vollständige Anwendungen umbauen. Es ist möglich, beispielsweise für eine Messe oder als Proof of Concept mit sehr geringem Aufwand und beschränktem Plattformwissen mobile Anwendungen zu launchen, ohne dabei allzu viel Zeit zu verschwenden.

React Native [3] hat sich hierbei als eines der populärsten Frameworks für derartige Anwendungsfälle herausgetan [1] [2]. Die Gründe dafür sowie eine kurze Einführung in die Konzepte inklusive einer Basis-Anwendung, die als Grundgerüst für die eigenen React-Native-Aspirationen dient, sind in diesem Artikel zu lesen.

Container, allen voran Docker, sind in aktuellen Infrastrukturen ein fester Bestandteil. Waren früher gerade Buildserver und CI-Umgebungen schwer zu warten, da diverse Werkzeuge oftmals jeweils in mehreren Versionen gepflegt werden müssen, können Build-Container alle benötigten Werkzeuge direkt mitbringen.

Moderne Buildserver wie DroneCI oder GitLab CI unterstützen daher nativ die Verwendung von Werkzeugcontainern in Form von Docker Images. Für Angular gibt es beispielsweise mit https://hub.docker.com/r/trion/ng-cli-karma ein Image, in dem Angular CLI und Webbrowser bereitgestellt werden.

In diesem Beitrag werfen wir einen Blick auf Cypress, dass sich sehr gut zur Umsetzung von Integrations- und Ende-zu-Ende Tests eignet. Cypress kann prinzipiell mit beliebigen Technologien kombiniert werden, beispielsweise serverseitig gerenderten Anwendungen, oder mit Angular, React oder Vue im Browser umgesetzten Anwendungen.
Wir verwenden in diesem Beispiel React, jedoch sollte die Übertragung auf andere Frameworks dem Entwickler sehr einfach von der Hand gehen.

Progressive Web Applications als Plattform der Zukunft war das Thema des Vortrages von Karsten Sitterberg auf der W-JAX 2019 in München.

Bei dem Vortrag wurden die verschiedenen Möglichkeiten, die sich durch aktuelle HTML5 APIs wie Web-App Manifest, Service-Worker und Web-Push ergeben anhand praktischer Beispiele demonstriert.

Neben den einzelnen APIs wurde am Beispiel einer Angular Anwendung demonstriert, wie die Unterstützung auf den aktuellen mobilen und Desktop Plattformen umgesetzt ist. Bei Angular ist die Umsetzung von offline-fähigen Anwendungen dabei sehr gut bereits durch das Framework unterstützt, so dass ein Entwickler relativ einfach eine PWA umsetzen kann.

Die Testpyramide ist sicherlich jedem vertraut.
Welche Unterschiede es neben einer theoretischen Einordnung gibt, zeigt Karsten Sitterberg in seinem Artikl "Tests an die Front".

In dem Beitrag im PHP Magazin liegt der Fokus auf Test von Webanwendungen. Neben klassischen Architekturen mit serverseitig gerenderten Webeiten werden JavaScript Clients als Single Page Applications betrachtet.

Eine Webanwendung läuft - und das ist gerade der große Benefit - nicht aussschließlich in einem Webbrowser auf einem Desktop Gerät. Mit zunehmend anspruchsvolleren Anwendungen müssen diese Rahmenbedingungen von Plattform und Displayformat bei Tests mit berücksichtigt werden.
Für Anwender zähle nämlich schon lange nicht mehr rein funktionale Gesichtspunkte, sondern auch nichtfunktionale Anforderungen wie Geschwindigkeit und eine gute Bedienbarkeit spielen eine Rolle.

In dem vierten Teil seiner Artikelserie rund um Testing von Web Anwendungen betrachtet Karsten Sitterberg nun spezielle Szenarien:
Dabei werden Fragen beantwortet, die sich um das Testen von HTML5 Anwendungen, Web-Anwendungen auf mobilen Endgräten beantwortet. Zudem wird erklärt, wie mit Devices in der Cloud getestet werden kann, wie sich eine Anwendung auf einer speziellen Plattform und dem zugehörigen Display-Format verhält.

In der Softwareentwicklung sollte es selbstverständlich sein, das Verhalten einer Anwendung stets basierend auf der fachlichen Spezifikation zu implementieren. Um sicherzustellen zu können, dass die fachlichen Vorganben eingehalten werden, werden Integrations- und auch Ende-zu-Ende-Tests (E2E-Tests) geschrieben.

Aufgrund ihrer jeweiligen Komplexität befinden sich die E2E-Tests in der Testpyramide über den Integrationstests, diese befinden sich über den Unit-Tests. Somit sollten sowohl Integrations- als auch E2E-Tests einen geringeren Anteil am geschriebenen Testcode haben als Unit-Tests. Im dritten Teil seiner Artikelserie hat Karsten Sitterberg beschrieben, mit welchem Vorgehen und welchen Tools bei der Erstellung eben solcher E2E- und Intergations-Tests vorgegangen werden kann.

Bei Web Anwendungen stellt sich die Frage nach einer guten Testbarkeit und auch nach einer guten Vorgehensweise bei Web Tests. Als grundlegende Metrik, um Aufwand und Menge der Tests abzuschätzen, hat sich die Testpyramide eingebürgert.

Auf der untersten Ebene befinden sich die Unit-Tests, die sich durch eine eher geringe Komplexität auszeichnen, dafür jedoch den Großteil der Tests ausmachen. Wie das Vorgehen bei der Erstellung von Unit-Tests aussehen kann, und welche Libraries und Frameworks bei Unit Tests für Webanwendungen helfen können, hat Karsten Sitterberg im zweiten Teil seiner Artikelserie zum Testen von Browser Anwendungen beschrieben.

Für manche Testszenarien muss auch ein Dateidownload mit getestet werden, z.B. um die resultierende Datei auf Korrektheit zu prüfen. Für Ende-zu-Ende Tests gibt es diverse Werkzeuge, eins davon ist das von Google entwickelte Puppeteer. Mit Puppeteer lässt sich aktuell der Chrome Browser fernsteuern, eine Erweiterung auf Mozilla Firefox ist ebenfalls in Arbeit.

In diesem Beitrag wird gezeigt, wie mit Docker und Puppeteer ein entsprechendes Testszenario umgesetzt werden kann.

Seitdem Frameworks wie Angular und React zusammen mit TypeScript die Möglichkeit eröffnen, komplexe Frontend Anwendungen zu erstellen, kommt auch die Frage auf, wie diese langfristig wartbar und erweiterbar konzipiert werden können. Als Antwort auf diese Frage liefert Karsten Sitterberg die bereits bei Backend-Anwendungen bewährte Herangehensweise des Test-Driven-Development (TDD) für Browser Anwendungen.

Im ersten Teil seiner Artikel Serie führt Karsten Sitterberg die grundlegenden Begriffe und Motivation für Tests von Webanwendungen ein und liefert einen Fahrplan für eine optimale Entwicklung einer gut getesteten Anwendung.
Dabei werden sowohl die Bedürfnisse der Entwickler klassischer (MVC) Webanwendungen, als auch von Single Page Application (SPA) berücksichtigt.

In Kundenprojekten steht immer wieder die Frage nach der richtigen Frontendtechnologie im Raum. Typischerweise fällt die Wahl dabei entweder auf "React" von Facebook oder "Angular" von Google.

Doch mit welchen Kriterien und Bewertungsmaßstäben geht man hier sinnvoll vor?

Welche der Optionen passt optimal zu den Anforderungen?