Offline-first apps mit WebComponents

Die Voxxed Days boten viele interessante Vorträge an. Ein Talk der mir persönlich gut gefallen hat war Offline-first apps mit WebComponents von Amahdy Abdelaziz. Im Fokus stand hauptsächlich die Offline-Funktionalität in Web-Apps und das Framework Vaadin, das unter anderem vom Vortragenden mitentwickelt wird. Das gleichnamige Unternehmen hat sich als Ziel gesetzt dieses freie Framework zu schaffen, um die Möglichkeit zu bieten, unkompliziert moderne sowie performante Webanwendungen zu entwickeln.

Abdelaziz versuchte den Besuchern zu erklären, dass die meisten Internet-User content-Konsumenten sind und sich nur ein sehr kleiner Teil mit dem Erzeugen von Inhalten beschäftigt. Statistiken zeigen, dass es seit Anfang 2014 global mehr User gibt, die mit mobilen Geräten wie Smartphones und Tablets das Internet besuchen als mit Desktops. Dies legt nahe den sogenannten Mobile-First Ansatz zu verwenden.

Was bringt dieses Konzept? In Wirklichkeit viele Vorteile wie einfachere Skalierbarkeit, höherer Fokus auf die wichtigsten Inhalte und eine bessere Übersicht über die Performance. Wie das möglich ist? Ist die Performance auf mobilen Geräten bereits während der Entwicklung nicht optimal, kann davon ausgegangen werden, dass es auch auf Desktops nicht optimal laufen wird. An dieser Stelle kommt das Vaadin Framework zum Einsatz. Mit den integrierten Web-Komponenten, die stark auf mobile Geräte ausgelegt sind, wird eine bessere User-Experience auf allen möglichen Plattformen erreicht – so Amahdy.

vaadin

Das erwähnte Offline-First Konzept wurde kompakt auf der Grafik präsentiert. Dieses ermöglicht eine einfache, übergangslose Verwendung einer Web-App, sowohl online als auch offline. Werden Änderungen durch den User durchgeführt, werden diese in die die lokale PouchDB geschrieben. Nun wird bei einer aktiven Internetverbindung eine Kopie der Daten auf die remote CouchDB kopiert. Sollte nun der User, zum Beispiel aus technischen Gründen, nicht über eine aktive Internetverbindung verfügen, werden die Änderungen nur lokal übernommen. Bei der nächsten Möglichkeit mit der remote Datenbank zu kommunizieren, wird die externe CouchDB mit der lokalen PouchDB synchronisiert.

Das schöne an der Lösung ist, dass der User nichts von diesem Vorgang mitkriegt und alles unter verschiedenen Bedingungen gleich funktioniert.

Der Demo-Code zur Präsentation mit dieser Funktionalität ist hier erhältlich.

 

Hiding secrets in a Vault

Einer der letzten Vorträge am zweiten Tag war hiding secrets in a Vault. Stjepan Hadjić, der Vortragende dieser Rede, meinte hiermit sicherheitskritische Daten wie zum Beispiel Zugangsdaten für Datenbanken oder Dienste, welche sich oft hard-kodiert im Quellcode befinden. Wieso das vermieden werden sollte, wurde sehr schön mit einem realen Beispiel erklärt.

Herr Carlo van Wyk hat seine Zugangsdaten, welche im Programmcode als Property gesetzt werden, nicht aus dem Quellcode extrahiert. Anschließend, anhand eines Plugins, legte er das Projekt als privates Repository auf dem GitHub Server ab. Nach ein paar Tagen empfing Carlo eine Amazon Rechnung per Email von fast 6.500$ für Gegenstände, welche er gar nicht bestellte. Jemand mit den gefundenen Zugangsdaten musste diesen Einkauf getätigt haben. Wie konnten die sensiblen Daten doch an die Öffentlichkeit geraten obwohl das Projekt privat war? Das verwendete Plugin hatte einen schweren Bug, wodurch das Projekt nicht als privat sondern öffentlich markierte. Verschiedene, speziell dafür ausgelegte Bots, durchschauen öffentliche Git-Repositories welche genau nach diesen sensiblen hard-kodierten Zugangsdaten suchen.

Aus diesem Grund sollen sensible Konfigurationsparameter immer außerhalb vom Quellcode gehalten werden. Es ist jedoch gar nicht so simpel die Informationen extern zu lagern und an Befugte zu verteilen. Das führte zur Entwicklung von Vault.

Die sicherheitskritischen Daten, die wir außerhalb unseres Quellcodes halten möchten, sollten in einer externen Datei liegen. Der Vortragende Stjepan hat sich für diesen Schritt für Figaro entschieden, das sehr gut mit Rails-Applikationen zusammenarbeitet. Es sollte nicht vergessen werden, dass das Config-File im .gitignore eingetragen werden muss.

Die Geheimnisse werden daraufhin in einem beliebigen Backend wie zum Beispiel MySQL, Consul oder PostgreSQL gelagert, per Vault wird auf diese dann per HTTP Rest API zugegriffen.

vault-authentication-authorization-flowVault unterstützt viele verschiedene Überprüfungsmethoden von Zugangsdaten, damit die dazugehörigen Mitglieder Zugriff auf dieselben sensiblen Daten erhalten. Zu diesen gehören Tokens mit LDAP, AppID aber auch das leicht bedienbare GitHub. Mit den konfigurierten Richtlinien können die Berechtigungen sehr präzise für die angegebenen Pfade erteilt werden. Durch die User-Verifizierungen gelangen die Entwickler schlussendlich zu den geheimen Konfigurationsparametern, die sich auch während der Entwicklung ständig ändern können. Diese werden mit Vault automatisch ausgelesen und nachfolgend im Projekt gesetzt. Somit wird sichergestellt, dass die Geheimnisse tatsächlich sicher verwahrt werden und die benötigten Daten jederzeit zur Verfügung stehen.

Hier befindet sich eine Art Terminal das den Konfigurationsvorgang von Vault erklärt.

Referenzen

Verlinkungen zu den angesprochenen Themen: