Ah. Sorry. Das ist definitiv noch ein Debug-Fehler.
Wird umgehend korrigiert mit Korrekturanweisung hier im Beitrag beschrieben zur Behebung. O_O
Dass ich DAS übersehen konnte o_O
Korrektur:
Datei: /content/intern/anmelden.php
Zeile: 140
Code:
db_query("INSERT INTO ".$db_prefix."_kontodaten (uid,passwort,status,hinweis,kontostand) VALUES ('".$_POST['uid']."','".md5($_POST['passwort_1'])."','1','','6000000000')");
Dort siehtman schon, wo der Fehler liegt. Die 6000000000 zu 0 ändern
Code:
db_query("INSERT INTO ".$db_prefix."_kontodaten (uid,passwort,status,hinweis,kontostand) VALUES ('".$_POST['uid']."','".md5($_POST['passwort_1'])."','1','','0')");
Fertig.
Der Fehler war schlichtweg ein "hab ich übersehen"-fehler. Dieser war drin um halt Debug-Tests problemlos durchführen zu können. Da ich mich bei der Installation nur als Admin angemeldet hatte, war dann das ganze von mir übersehen worden.
Edit:
1. Ich denke ich werde das Setup so ändern, dass die seite grundsätzlich im Wartungsmodus startet.
2. Unabhängig des Faker-Users hat er doch geholfen. Sonst wär uns der Fehler nich so schnell aufgefallen.
3. Ich werde gegebenenfalls eine Global-Ban-List mit einbauen, welche eine zentralanlaufstelle bietet, um user auf fast allen seiten auszusperren. Aber auch um einzelne ausgesperrte user zuzulassen. Inklusive abschaltbarkeit usw. So kann man faker/hacker/botuser sehr schnell global loswerden.