Spring und HTML5: Frühling für den Browser

Authentifizierung

Der Browser unterstützt von sich aus lediglich eine BASIC-Authentifizierung, die durch ein sehr einfach gehaltenes Popup-Fenster durch den Browser ausgeführt wird. Daher greift man häufig auf anwendungsspezifische Login-Formulare zurück, die eine Anmeldung auf dem Server durchführen. Dadurch wird allerdings die Steuerung des Login-Prozesses vom Server übernommen, was einen Bruch in der Architektur darstellt.

Eine bessere Lösung für dieses Problem stellt die Auslagerung der Authentifizierung auf den Client dar. Sobald der Server eine nicht authentifizierte Anfrage für eine geschützte Ressource erhält, gibt er eine einfache „403-Forbidden“-Meldung zurück. Auf dem Client wird diese Antwort über eine generische Interceptor-Lösung, die das AngularJS-Framework bereitstellt, abgefangen und in diesem Fall ein Login-Dialog angezeigt. Nach der erfolgreichen Anmeldung durch den Benutzer wird die ursprüngliche Anfrage an den Server wiederholt. Durch diese Lösung wird sichergestellt, dass auch der Login-Prozess im Rahmen clientseitigen Architektur umgesetzt wird.

Autorisierung

Solange der Server die Generierung des HTML-Markup übernimmt, werden nur diejenigen Fragmente ausgeliefert, die auch der Benutzer sehen darf. Bei einer AngularJS-basierten Anwendungen findet keine Aufbereitung von HTML-Markup auf dem Server statt. Daher wird immer der gesamte HTML-Markup einer Seite auf den Browser übertragen.

Im einfachen Fall können die HTML-Dateien auf dem Server rollenspezifisch abgelegt werden. Dadurch können die Benutzer nur solche HTML-Dateien abrufen, für die sie berechtigt sind. Im komplexeren Fall müssen Inhalte einer HTML-Datei rollenspezifisch im Browser aus- oder eingeblendet werden. Dies kann jedoch durch den Benutzer innerhalb des Browser böswillig beeinflusst werden.

In erster Linie muss in diesem Fall sichergestellt werden, dass sämtliche REST-Ressourcen nur die Daten enthalten, für die der Benutzer berechtigt ist. Dadurch werden Daten, die der Benutzer nicht sehen darf, erst gar nicht auf den Client übertragen. Selbst bei einer Manipulation wird dem Benutzer zwar HTML-Markup angezeigt, jedoch enthält dieses keine Daten. Um letzteres auszuschließen, müssen zusätzlich die HTML-Seiten durch den Server aufbereitet werden.

Internationalisierung

Bei serverseitigen Anwendungen wurde die Internationalisierung analog zur Autorisierung auf dem Server durchgeführt. Dadurch wurden die HTML-Seiten beim Ausliefern zum Client in die jeweilige Zielsprache übersetzt. Bei einer clientseitigen Anwendung muss ebenfalls eine Lösung gefunden werden. Dabei kommen unterschiedliche Ansätze in Betrachtung.

Die Übersetzung geschieht vollständig im Browser. Dabei werden die Texte als properties-Dateien vom Browser abgerufen [9]. Problematisch sind hierbei die Sicherheit (alle Texte der Applikation sind offen verfügbar) sowie die Menge der Daten.

Die Texte werden wie bisher auch im Server übersetzt. In diesem Fall müssen alle AnguarJS Templates vom Server aufbereitet werden, und somit dort eine Templating-Technologie verwendet werden.

Die Übersetzung erfolgt während des Build-Prozesses, dadurch existieren für jede Sprache zur Laufzeit eigene HTML-Dateien. Hierbei muss bei jeder Änderung die komplette Applikation neu erstellt werden.

Fehlerbehandlung

Grundsätzlich kann jede Anfrage an den Server ein Problem verursachen und mit einer Fehlermeldung enden. Diese sollte dann in geeigneter Form dem Benutzer angezeigt werden. Spring-MVC wie auch AngularJS bieten geeignete Erweiterungspunkte, um eine elegante Fehlerbehandlung zu implementieren. In Spring gibt es HandlerExceptionResolver, die immer dann aufgerufen werden, wenn eine Exception nicht innerhalb der Applikation behandelt wird. Ein solcher Resolver kann im Fehlerfall dazu genutzt werden, ein Fehlerobjekt aufzubauen, das die Details zu der Exception enthält, und zum Browser geschickt wird. Über die bereits erwähnten Interceptoren von AngularJS können Fehler abgefangen und dem Benutzer in geeigneter Form angezeigt werden. Dadurch kann wie bei serverseitigen Anwendungen auch eine zentrale Fehlerbehandlung umgesetzt werden.

Fazit

Dieser Artikel kann nur einen kleinen Ausschnitt dessen zeigen, was mit aktuellen Browsertechnologien möglich ist. Wie im ersten Teil des Artikels beschrieben, können auch heutige Anwendungen ohne größere Änderungen von HTML5-Technologien profitieren. Darüber hinaus zeigt der Artikel im zweiten Teil die Möglichkeiten und Herausforderungen im Bau von komplexen Webapplikation auf Basis von JavaScript-Technologien auf. Dadurch erschließen Webapplikationen neue Anwendungsgebiete, bei denen früher häufig Browser-Plug-ins (Flash, Silverlight und andere) zum Einsatz gekommen sind. Die Tatsache, dass die hier vorgestellten Standards und Tools größtenteils noch in der Entwicklung sind, verdeutlicht neben den Problemen auch die neue Chancen und Möglichkeiten, die sich dadurch ergeben.

Agim Emruli ist Geschäftsführer und Softwarearchitekt bei mimacom. Davor hat er bei SpringSource Kunden beim Einsatz von Open-Source-Technologien beraten. Agim ist erreichbar unter agim.emruli [at] mimacom.com.

Stefan Niederhauser ist ebenfalls Softwarearchitekt bei mimacom. In letzter Zeit beschäftigt er sich eingehend mit neuen Webtechnologien und Frameworks wie z. B. AngularJS. Seine E-Mail lautet stefan.niederhauser [at] mimacom.com.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.