Die selbstlöschende Benutzertabelle

Vor vielen Jahren habe ich eine Website "geerbt", die viele benutzergenerierte Inhalte enthält. Ich kann hier nicht auf Details eingehen, um die unschuldigen Schuldigen - und mich selbst - zu schützen.

Unbekanntes Objekt

Es basierte auf einem Framework, von dem ich nichts wusste, so dass das externe Unternehmen, das es erstellt hat - nennen wir sie Initech - auch den Code pflegte. Wir haben die Server verwaltet. Die Webseite hatte verschiedene Arten von Einträgen, die alle in separaten Tabellen gespeichert wurden.

Kleinere Wartungsarbeiten wurden von uns durchgeführt - wie das Ändern von HTML-Vorlagen oder das Optimieren der Datenbankabfragen, um die Serverlast zu verringern -, aber neue Funktionen müssen von Initech erstellt werden. Im Laufe der Zeit wurden ein paar Dinge verfeinert und alles lief gut mit.

Bis ich eines Tages einen Anruf bekam: "Simon, niemand kann sich mehr einloggen!". Ich habe den Server überprüft und festgestellt, dass die meisten Benutzer fehlten. Erst vor wenigen Tagen hat ein neuer Mitarbeiter die Verwaltung der Daten auf dieser Website übernommen, sodass wir davon ausgegangen sind, dass er auf etwas Falsches geklickt hat. Ich stellte die Benutzerdaten aus dem Backup wieder her und hoffte, dass dies nicht noch einmal geschehen würde, machte mir aber immer noch Sorgen, warum dies überhaupt passiert ist. Um auf der sicheren Seite zu sein, haben wir die Sicherungsfrequenz erhöht. Wie Sie sich vorstellen können, ist es wieder passiert. Gleich am nächsten Tag. Das Seltsame war, dass nicht alle Benutzer weg waren, sondern rund 90%. Der Rest blieb. Bevor ich eine weitere Wiederherstellung durchführte, exportierte ich die dezimierte Benutzertabelle, um herauszufinden, was an den verbleibenden 10% so besonders war, und richtete eine Entwicklungsinstanz ein, um verschiedene Dinge selbst auszuprobieren.

Wir hätten uns einfach an Initech wenden können, aber das hätte ein paar Tage gedauert, und in der Zwischenzeit wollte ich nicht ständig Dinge wiederherstellen, die aus unbekannten Gründen verschwunden waren. Vielleicht war sogar jemand in die Webseite eingebrochen. Auch ich war sehr neugierig. Zuerst wollte ich herausfinden, wo alle Löschungen im Code passiert sind. Da dies in einer Skriptsprache geschrieben war, konnte ich einfach die gesamte Codebasis durchsuchen. Die meisten Löschungen waren gutartig, aber eines kam mir seltsam vor. Es kam von einem neuen Teil, der kürzlich hastig auf die Website geschrieben wurde und "abgelaufene" Datensätze löschte. Das Seltsame war, dass der Tabellenname für die Löschabfrage aus einer Variablen übernommen wurde und es keine Liste gab, aus welchen Tabellen gelöscht werden sollte. Aus Versehen habe ich versucht, diese Abfrage mit der Benutzertabelle abzugleichen, und raten Sie mal, sie passt. Alle Felder überlappten sich, und zufällig war in der Benutzertabelle auch eine Spalte vorhanden, mit der der Ablauf eines Datensatzes überprüft wurde, die jedoch eine andere Bedeutung hatte, was bedeutete, dass sie für fast alle Benutzer festgelegt wurde.

Ok, das ist der wahrscheinlichste Schuldige. Aber was heißt es überhaupt? Als dieses automatische Löschen implementiert wurde, konnten wir keinen Cronjob einrichten, und meines Wissens verfügt dieses Framework über keine eingebaute Cron-Funktion. Wo passiert es also? Ja, natürlich passiert es, wenn man versucht, die Tabellen im Backend anzuzeigen. Denn dort soll man es ausdrücken, oder? .... Recht...? Es gab eine Möglichkeit, Benutzerkonten zu bearbeiten, sodass niemand die Benutzertabelle über dieses System direkt anzeigen konnte. Mit Ausnahme des neuen Mitarbeiters, der sich mit dem System vertraut machen und auf alle Tabellen in der Liste klicken wollte. Als ich es in meinem Entwickler-Setup versuchte, dauerte es eine Weile, bis die Benutzertabelle geladen war, während die Festplatte durch die Datenbank geschliffen wurde. Dabei wurden alle vor mehr als einem Jahr mit diesem bestimmten Flag erstellten Benutzerkonten gelöscht. Ich entwickelte schnell einen einzeiligen Fix, der die Tabellennamen anhand einer Whitelist vergleicht und sofort in der Produktion bereitstellt. Außerdem habe ich Initech eine E-Mail über die Änderungen geschickt - auch mit einer dezenten Bemerkung, dass wir einen Cronjob diesem Durcheinander vorgezogen hätten ...