Go Projekt Layout

Der pkg-Ordner ist ein Antipattern

An gut findbarer Stelle im Internet (ich werde sie nicht verlinken, weil sie dann nur noch mehr Relevanz bekommt), findet sich eine Go Modul Struktur, in der angeregt wird, einen pkg Ordner anzulegen für Pakete, die das Programm in dem Modul betreffen.

Wenn die Pakete jedoch tatsächlich nur das Programm betreffen, sollten sie in einem Ordner internal befinden. Das ist tatsächlich Dokumentiert und sorgt dafür, dass diese Pakte nicht Teil derÖffentlichen API sind.

Der pkg Ordner keinerlei semantischen oder informellen Wert und sollte deshalb ganz verschwinden. Hatte ich also ein total tolles neues Kompressionsverfahren - nennen wir es MyZap - entwickelt und möchte es als Bibliothek sowie als CLI-Tool veröffentlichen, hätte ich etwa folgende Projektstruktur:

cmd/
 +- myzipper/
        main.go
internal/
 +- ui/
    ...
 +- cfg/
compress/
    lib.go
    ...
go.mod
go.sum
license
readme.md
Makefile

Damit ließe sich das Programm einfach mit go get installieren und über import die Bibliothek benutzen. Irgendwelche statischen Webseiten, Konfigurationen etc., gehören damit dann auch in den internal Ordner, da die definitiv nicht Teil der öffentlichen API sind.

Viel schöner und genauer lässt sich das hier nachlesen: Simple Project Layout with Modules

Web API Checklist

Es ist mit ein paar Herausforderungen verbunden, wenn die API, die vorher nur aus dem gesicherten Intranet erreichbar war, plötzlich über das internet verfügbar gemacht wird. Die anzahl der potenziellen Benutzer schießt in die Höhe und damit auch die Anzahl der Menschen, die Unsinn damit treiben mögen.

Jeder hat eine öffentliche Web-API!

“Meine API wird ja nur von meiner App aufgerufen." Habe ich tatsächlich schon mehrfach gehört. Aber wenn die App von öffentlichen Rechnern funktionieren soll, muss die API öffentlich erreichbar sein.

Die Checkliste

Die Liste erhebt keinen Anspruch auf Vollständigkeit. Es sind die Punkte, die mir als erstes einfallen, weil sie in meinen Projekten häufig auftauchen.

Zugriffsrechte

• Zugriffsrechte festlegen und testen. Das klingt ersteinmal ziemlich naheliegend. Aber es reicht jetzt nicht mehr, ob ein Button im Frontend nicht mehr auftaucht. In jedem Request muss deshalb die BenutzerId und eine Liste der Gruppen mitgeschickt werden. Das lässt sich mit einem AWT relativ einfach abbilden. Das Backend muss jetzt überprüfen, ob dieser Benutzer berechtigt ist etwas mit diesen Daten zu machen. Wir möchten nicht, dass ein Benutzer René die Daten von Klaus ändern kann, nur weil beide in der Gruppe Benutzer sind. Diese Dinge müssen getestet werden. Automatisiert. Immer. Bei jedem Build.

  Ich würde zusätzlich die Gruppenrechte noch einmal im Reverse Proxy überprüfen und um Zweifelsfall gar nicht erst an das Backend weiterleiten. Es gibt dafür schöne Plugins für zb Nginx.

• Security Provider nicht selber Programmieren. So wie man keine Datenbanken selber entwickelt, sollte man auch IDM und Logins nicht selber implementieren. Es gibt dazu gute, geprüfte Implementationen wie zB Keycloak. AM und IDM sind komplexe Themen. Wenn es nicht der Kern Businesscase von deinem Unternehmen ist, lass es einfach.

• Keine fortlaufenden IDs verwenden. Wenn tatsächlich einmal etwas schief geht (und das wird es), ist es hilfreich, wenn nicht jeder Idiot sofort mit einem 2 Zeilen Script alle Daten abgreifen kann. Wenn ich mit einfachem Hochzählen der Id immer einen Treffer lande, wird es auch schwierig, die Ip des bots als illegalen Zugreifer zu identifizieren und länger zu sperren. (s.u.)

  Das geht zB mit UUIDs aber auch mit Pseudo Encrypt oder XTEA.

• 404 statt 403. Wenn René die Daten von Klaus anfragt, sollte er ein Nicht Gefunden (404) als Antwort erhalten und nicht ein Keine Berechtigung (403). Wir müssen dem Hacker René ja nicht unbedingt mitteilen, dass er mit der Id einen Treffer gelandet hat. Wenn ich Daten bereits sehen kann, weil ich vielleicht Leserechte habe, dann antworten wir natürlich mit 403. Sonst dreht der Support durch.

Richtigkeit der Daten

• Listen Anfragen beschränken Niemand, wirklich niemand sollte mit einem API Call die ganze Datenbank auslesen dürfen. Sowas wie Gib mir alle Artikel mit einem Limit von 5 Millionen macht keinen Sinn. Das maximal zulässige Limit sollte so klein wie möglich gewählt werden.

• Eingabedaten beschränken. Die maximale Größe einen Post Objekts sollte eingeschränkt sein. Die Überprüfung sollte so weit vorne in der Kette wie möglich erfolgen - sollte also im Reverse Proxy eingestellt werden.

• Eingabedaten validieren Praktisch jede Programmiersprache hat eine einfach zu verwendende Bibliothek zur Datenvalidierung. (zB Go Validator) Benutzt sie. Idealerweise kommt eine unsinnige Anfrage nicht einmal bis zur Business Logik - geschweige denn bis zur Datenbank. Kann man mit Fuzzing überprüfen.

Lastbegrenzung

• Aufruffrequenz beschränken. Selbst wenn wir einen sehr ungeduldigen Kunden haben, der wirklich sehr schnell klicken kann, gibt es vermutlich ein sinnvolles Limit, das eine regulär laufende Anwendung nicht überschreiten wird. Rate Limiter sind so üblich, dass man sie meist nicht selbst implementieren muss. Hier ein Beispiel für Nginx.

• Fehlerhafte anfragen blocken. Das ist im prinzip ähnlich wie der vorherige Punkt, nur dass hier bei häufigen Anfragen, die mit Fehlern beantwortet werden, die anfragende Ip länger gesperrt wird. Das geht zB mit dem Klassiker fail2ban