Tach!
Es gibt im Wiki einen neuen Artikel, der beschreibt, wie man das versehentlich mehrfach gesendete Formulardaten serverseitig erkennt und darauf reagieren kann. Benutzer:Apsel/Reloadsperre
Es sollte ein Hinweis eingefügt werden, dass PDO als DB-Layer verwendet wird und dass der Verbindungsaufbau im Beispiel weggelassen ist, oder dass $db ein erfolgreich initialisiertes PDO-Objekt darstellt. Das kann man sonst nur aus dem Code selbst herauslesen, wenn man PDO schon kennt. Ich plädiere für einen Kommentar in der ersten Code-Zeile, der Herkunft/Inhalt von $db kurz erklärt. Und dann sollte zumindest die Fehlerbehandlung angedeutet werden.
$id_check ist nicht gerade ein passender Variablanname. $db->prepare() liefert ein PDOStatement, keine ID-Check-Objekt. Oft bennennt man diese Variable $stmt. Wenn es unbedingt sprechender sein muss, dann $stmt_id_check oder so. Wenn die Lebenszeit dieser Variable nur wenige beieinander stehende Codezeilen umfasst, und es keine Dopplungen gibt, dann reicht ein einfaches $stmt.
Für Dinge, die es nur einmal in der Datenbank geben darf, nimmt man einen Unique-Index. (Der kann auch über mehrere Spalten angelegt werden.) Dann nimmt man ein einfaches Insert und prüft ob das mit einem Duplicate-Key-Fehler zurückkommt oder fehlerfrei durchläuft. Wenn man solcher Daten vorher mit Select prüft, handelt man sich ein TOCTTOU-Problem ein. Ein Select zum prüfen kann man vielleicht für eine Ajax-unterstützte Eingabe nehmen. Aber das ist mit Vorsicht zu genießen, weil das auch zur Abfrage von existierenden Benutzernamen missbraucht werden kann. - Der doppelte Benutzer ist also kein geeigneter Fall für die Reload-Sperre.
Die Funktion array_push() lohnt sich nur, wenn mehrere Werte gleichzeitig angehängt werden sollen. Sonst ist $foo[] = 'bar'; die einfachere Variante.
Wenn man ein Einmal-Token als Lösung nimmt, kann man eigentlich auch gleich einen CSRF-Schutz verwenden, da hat man gleich zwei Fliegen mit einer Klappe geschlagen.
Ein besseres Anwendungsbeispiel, was nicht mit Unique-Key oder einfacher Weiterleitung oder dem möglicherweise sowieso notwendigen CSRF-Schutz erledigt ist, fällt mir grad nicht ein.
dedlfix.