Fargo-Sicherung ist bei image² ein interner Begriff für eine zusätzliche Absicherung gegen unerwartetes, unlogisches oder schlicht nicht vorhersehbares Nutzerverhalten.
Der Grundgedanke ist einfach: Eine Funktion darf nicht nur dann zuverlässig funktionieren, wenn Menschen sie genau so bedienen, wie wir uns das bei der Entwicklung vorgestellt haben.
Denn irgendwann klickt jemand auf etwas, von dem wir überzeugt waren, dass dort wirklich niemand draufklicken würde.
Warum heißt es Fargo-Sicherung?
Der Begriff geht auf Douglas Fargo aus der Fernsehserie Eureka zurück.
Fargo ist unter anderem dafür bekannt, auf Knöpfe zu drücken – einfach deshalb, weil sie da sind. Selbst wenn ziemlich eindeutig ist, dass er den Knopf besser nicht drücken sollte. Selbst wenn er weiß, dass dadurch etwas schiefgehen könnte. Und gelegentlich sogar dann, wenn eine Katastrophe praktisch angekündigt ist.
Der Knopf ist da. Also wird er gedrückt.
Für die Entwicklung von Websites und Anwendungen ist das eine erstaunlich brauchbare Denkweise.
Denn auch echte Nutzerinnen und Nutzer halten sich nicht zwangsläufig an den Ablauf, den wir beim Entwickeln vor Augen hatten. Sie klicken Dinge in einer unerwarteten Reihenfolge an, führen Aktionen mehrfach aus, gehen zurück, öffnen mehrere Tabs, ändern bereits abgeschlossene Eingaben oder betätigen einen Button, bei dem wir uns beim Programmieren gedacht haben:
„Warum sollte irgendjemand jetzt darauf klicken?“
Genau an dieser Stelle kommt die Fargo-Sicherung ins Spiel.
Der Fargo-Test
Beim Testen einer Funktion prüfen wir selbstverständlich zuerst, ob der vorgesehene Ablauf funktioniert. Danach kommt bei relevanten Funktionen eine zweite Frage:
„Was passiert, wenn Fargo davor sitzt?“
Also zum Beispiel:
- Was passiert, wenn jemand diesen Button zweimal anklickt?
- Was passiert, wenn jemand zuerst B, dann A und danach wieder B auswählt?
- Was passiert, wenn jemand nach dem Absenden mit dem Browser zurückgeht?
- Was passiert, wenn eine bereits abgeschlossene Aktion noch einmal gestartet wird?
- Was passiert, wenn jemand während eines Vorgangs seine ursprüngliche Auswahl ändert?
- Was passiert, wenn dieselbe Funktion gleichzeitig in zwei Tabs geöffnet ist?
- Was passiert, wenn jemand genau auf das Element klickt, bei dem wir gerade gesagt haben: „Da klickt doch kein Mensch drauf“?
Der letzte Fall ist besonders verdächtig.
„Weil Benutzer.“
In unseren Code-Kommentaren findet sich für solche Absicherungen deshalb gelegentlich eine ausgesprochen kurze technische Begründung:
/**
* FARGO-SICHERUNG
*
* Weil Benutzer.
*/Das ist keine vollständige technische Dokumentation. Als Begründung für die Existenz der zusätzlichen Prüfung ist es allerdings erstaunlich präzise.
Eine Fargo-Sicherung unterstellt dabei weder böse Absicht noch mangelndes technisches Verständnis. Menschen benutzen Oberflächen einfach nicht immer so, wie Entwicklerinnen und Entwickler es erwarten. Manchmal probieren sie etwas aus. Manchmal klicken sie zu schnell. Manchmal ändern sie ihre Meinung mitten im Vorgang. Und manchmal ist ein Knopf eben da.
Fargo-Sicherung ist nicht dasselbe wie Security
Eine Fargo-Sicherung kann gleichzeitig eine Sicherheitsfunktion sein, muss es aber nicht.
Bei klassischer Security geht es beispielsweise darum, Manipulationen, unerlaubte Zugriffe oder veränderte Requests abzufangen.
Beim Fargo-Prinzip geht es zunächst um eine andere Frage:
„Kann jemand durch eine unerwartete Bedienung einen Zustand erzeugen, mit dem unsere Anwendung nicht umgehen kann?“
Die technische Lösung hängt vom jeweiligen Fall ab. Ein Button kann nach dem ersten Klick deaktiviert werden. Eine Aktion kann vor ihrer Ausführung noch einmal geprüft werden. Veraltete Werte können verworfen werden. Ein bereits abgeschlossener Vorgang kann gegen eine erneute Ausführung geschützt werden. Kritische Daten können vor der Verarbeitung serverseitig validiert werden.
Serverseitige Validierung ist damit eine mögliche Fargo-Sicherung – aber Fargo-Sicherung bedeutet nicht automatisch serverseitige Validierung.
Ein einfaches Beispiel
Ein Formular enthält eine Auswahl. Abhängig davon werden weitere Felder eingeblendet und ein Preis berechnet.
Der vorgesehene Ablauf lautet:
Auswahl treffen → Angaben ergänzen → Preis berechnen → Formular absenden.
Das funktioniert. Damit ist die Funktion aber noch nicht unbedingt fargosicher.
Was passiert beispielsweise, wenn jemand eine Auswahl trifft, alle zusätzlichen Felder ausfüllt, danach die ursprüngliche Auswahl wieder ändert und anschließend das Formular absendet?
Bleiben alte Werte erhalten? Wird der Preis neu berechnet? Entsteht eine Kombination von Daten, die eigentlich gar nicht möglich sein sollte?
Eine Fargo-Sicherung sorgt dafür, dass auch ein solcher Ablauf zu einem definierten und sinnvollen Ergebnis führt.
Wie viel Fargo-Sicherung ist sinnvoll?
Natürlich können wir nicht jede theoretisch mögliche Klickkombination vorhersehen.
Eine Fargo-Sicherung ist vor allem dort sinnvoll, wo ein unerwarteter Ablauf relevante Folgen haben könnte: falsche Preise, doppelte Buchungen, widersprüchliche Daten, mehrfach ausgeführte Aktionen oder Zustände, aus denen Nutzerinnen und Nutzer nicht mehr sinnvoll herauskommen.
Der Maßstab ist also nicht:
„Könnte theoretisch irgendjemand irgendwann irgendetwas Seltsames machen?“
Sondern:
„Wenn jemand hier etwas völlig Unerwartetes macht – kann dabei etwas kaputtgehen?“
Wenn die Antwort Ja lautet, lohnt sich meistens ein Blick darauf, ob noch eine Fargo-Sicherung fehlt.
Fargo-Sicherung im image² Dev-Wiki
Wenn in einem anderen Eintrag des image² Dev-Wikis von einer Fargo-Sicherung die Rede ist, bedeutet das:
Diese Funktion enthält bewusst eine zusätzliche Absicherung für einen Ablauf oder eine Aktion, die eigentlich nicht vorgesehen ist, die ein Mensch aber trotzdem ausführen könnte.
Welche technische Maßnahme damit gemeint ist, steht beim jeweiligen Eintrag.
Und sobald bei der Entwicklung der Satz fällt:
„Aber warum sollte irgendjemand das machen?“
lautet die Antwort sicherheitshalber:
Weil Benutzer.