Mittwoch, 14. September 2016

Robust Code: Update von Daten mittels Switch

Stell dir vor du downloadest regelmäßig eine Datei, die du danach weiter verarbeitest. Hier zur Illustration als Bash:

curl -sS "http://eber-p.com/report.csv" | wc -l

Wenn jetzt der Download aus irgend einem Grund fehlschlägt, dann bricht die Datenverarbeitung ab. Dein Service liefert keine Ergebnis mehr. Hier pflanzt sich ein Fehler durch mehrere Systeme fort. Das kann gewollt sein, meistens möchte man aber eine robuste Lösung die nicht bei jedem Downloadfehler zusammenbricht. Dies kann man erreichen, in dem man die alte Datei nicht überschreibt, sondern als Fall Back behält und sie ggf. erst nach einem erfolgreichen Download überschreibt.

wget "http://eber-p.com/report.csv" 
r=`ls -t report.csv* | head -n 1`
cat $r | wc -l   


Wichtig ist nur, dass man die Benutzung des Fall Backs dokumentiert, im Log File und oder in der Antwort des Services. Letztere wird hier nicht gemacht.

Kurz zusammengefasst die robuste Softwarelösung:

  1. Lose Kopplung von Programmteilen die unterschiedliche Funktionen hat, hier Datenbeschaffung und Logik (hier zählen der Zeilen des Reports). 
  2. Puffern von alten Daten und Nutzung von diesen Daten als Fallback.

Zum Thema hier noch ein passender Link. Dort wird diese Problematik unter dem Begriff Be Atomic beschrieben.

Hier das ganze Beispiel-Skript:
#! /bin/sh

echo "Test with right URL"
u="http://ebert-p.com/report.csv"

echo "Non robust code"
curl -sS  $u | wc -l

echo "Robust code"
wget -q -a log.log  $u
r=`ls -t report.csv* | head -n 1`
cat $r | wc -l         


echo "Test with wrong URL"
u="http://ebert-p.com/report_wrong.csv"

echo "Non robust code"
curl -sS  $u | wc -l

echo "Robust code"
wget -q -a log.log  $u
r=`ls -t report.csv* | head -n 1`
cat $r | wc -l   

Und die Konsolen Ausgabe:
Test with right URL
Non robust code
    1518
Robust code
    1518
Test with wrong URL
Non robust code
      24
Robust code
    1518

Nicht-Funktionale Anforderung: Software Robustness

Robustheit ist die Toleranz gegenüber Fehlern. Robustheit gehört damit zu den nicht-funktionalen Anforderungen. Die Toleranz gegenüber Fehlern kann auf unterschiedliche Weise realisiert werden. Systeme gelten als robust, wenn sie folgende Eigenschaften hat:

  1. Ein Fehler führt nicht zum Ausfall des gesamten Systems.
  2. Das System kann Fehler selbst beheben oder umgehen.
  3. Die Auswirkung eines Fehlers bleiben lokal begrenzt, sowohl aus zeitlicher als auch aus Systemsicht.

Robustheit zahlt direkt auf die Verfügbarkeit von Systemen ein, sowohl was die Häufigkeit von Störungen als auch auf den zeitlichen Umfang der Störung angeht. Oder anders formuliert, robuste Softwaresysteme haben eine höhere Verfügbarkeit als weniger robuste Softwaresysteme.

Robustheit kann durch verschieden Massnahmen erreicht werden:

  1. Redundanz
  2. Robuste Software Architektur
  3. Exception Handling
  4. Fall Backs
  5. Funktionsreduktion

Alles was man nicht testet funktioniert auch nicht, so auch Software Robustheit. Deswegen muss Robustheit auch durch Robustheitstests gesichert werden.

Dienstag, 13. September 2016

Sicherheitsproblem API Token

API Token sind eine einfache Möglichkeit um den Zugriff auf z.B. Rest API zu steuern. Ein API Token ist in der Regel ein längerer String mit zufälligem Inhalt, der dem Programmierer den Zugriff auf das API erlaubt. Der Benutzer bzw. Programmierer wird identifiziert sich mittels des API Tokens. Wie Kristopher Sandoval in seinem Blog Artikel ausführt, sollten man kritisch auf die scheinbare Sicherheit der API Token schauen. Zum Umgang mit API Token hier ein paar Tipps:

  1. Einen API Token sollte man wie privaten SSH Key behandeln. 
  2. Man sollten ihn auf keinen Fall innerhalb des Projektes, egal ob in einer plain Textdatei oder im Code haben. 
  3. Im einfachsten Fall sollte man den API Token im hoffentlich gesicherten User Verzeichnis ablegen, auf dem hoffentlich verschlüsseltem Disk Volumen.
  4. Bei Rest APIs sollte der API Token nur per sicherem HTTPS benutzt werden.
  5. Der API Token sollte nie in öffentliche Code Repos wie Github gepostet werden. Das Entfernen von solchen Git Pushes ist kein Spass. Hier kann ein Git Hook (pre-commit) hilfreich sein, der den Code nach verdächtigen Strings oder Dateien durchsucht.
  6. Auch sollten sie nicht in Wikis abgelegt werden.

Links: