Hallo Leute,

ich bastel gerade eine einem Loginsystem mit Registrierung und denke über folgendes nach. Wenn Ein username ja sowieso eindeutig sein muss (nur einmal vorkommen darf) dann kann ich den doch auch als Primary KEy nehmen oder? Und dann wollte ich noch Fragen:
Bei der Verarbeitung des Anmeldeformulars lese ich momentan alle Namen, Nachnamen, Usernamen und EMail adressen aus und vergleiche diese mit der Eingabeim Formular.. ist das sinnvoll? Ich meine, es sollte sich ja nicht jeder mit einer E-Mailadresse oder mit dem gleichen Vor-und Nachnamen undvor allem nicht mit dem gleichen Usernamen mehrmals registrieren.. oder sehe ich das falsch? Ich würde gernem al hören wie ihrdas machen würdet... bzw. was da sinnvoll ist.

Wenn du die Logindaten aus dem Anmeldeformular in der Hand hast, dann genügt

SELECT <die gewünschten Spalten> FROM tabelle
WHERE <Spalte Benutzername>='<Benutzername aus Formular>
AND <Spalte Passwort>=<Crypt-Funktion>(<Passwort aus Formular>)

wobei Crypt-Funktion natürlich deiner Verschlüsselung entsprechen muß (MD5, PASSWORD, ...).

Du brauchst hierbei auch kein "LIMIT 1" benutzen, weil diese Abfrage immer maximal einen Datensatz liefert, wenn du das durch die Einzigartigkeit des Benutzernamens oder der Kombination aus Benutzernamen und Passwort sicherstellst.

Also okay, ich suche die Benutzernamen raus, die mit dem eingegebenen Benutzernamen identisch sind, das ist klaro, aber warum sollte ich die auslesen, die das gleiche Passwort haben??? ZWei Benutzer können doch durchaus das gleiche Passort haben, odeR?

Ich finde z.B. viel wichtiger, dass man sich nur 1 mal mit einer E-mail Adresse anmelden kann, oder?

Original geschrieben von Lexus_Ks
Also okay, ich suche die Benutzernamen raus, ...
den Benutzernamen, denn es gibt nur einen. Benutzernamen sind eindeutig oder?
aber warum sollte ich die auslesen, die das gleiche Passwort haben??? ZWei Benutzer können doch durchaus das gleiche Passort haben, odeR?
Du liest den Datensatz, wo beides, Name und Passwort stimmen. Wenn du das Passwort nicht mit prüfst, kann ich mich als jeder x-beliebige User anmelden, wenn ich dessen Namen nur mal irgendwo gelesen habe. Das kannst du nicht wollen!
Ich finde z.B. viel wichtiger, dass man sich nur 1 mal mit einer E-mail Adresse anmelden kann, oder? [/B]Deine Entscheidung, prinzipiell aber eine gute Idee. Spielt beim Anmelden aber nur dann eine Rolle, wenn man im Anmeldeformular auch seine Mailadresse eintippen muß. Das wäre überflüssig, denn Name und Passwort identifizieren einen User bereits eindeutig.

Huch.. ich glaube das ist falsch rübergekommen... es geht hier um die registrierung ... lol.. sorry für meinen falschen Ausruck.

Hm, das hätte dir schon einfallen könne, als ich mit SELECT anfing.

Was willst du denn jetzt, wo ist das Problem? Eindeutigkeit erreichst du durch UNIQUEness der entsprechenden Spalten. Ein Primärschlüssel ist immer eindeutig.
Formulardaten per UPDATE eintragen, wenn es fehlschlägt mit "SELECT ... WHERE ..." eine Kriterium nach dem anderen testen, bis du das gefunden hast, was schon vorhanden ist. Entsprechende Fehlermeldung ausgeben. Fertig.

Ja ^^ Also meine Frage ist erstens, wie sinnvoll es ist ín der Usertabelle den Username als Primary Key zunehmen (anstatt einer ID) und meine Zweite ist, was man noch als eindeutiges Kriterium nutzen sollte (sprich was nur bei einem User vorkommen darf).

Benutzernamen sind Namen und nicht nur auto_increment-Werte, weil man sie - und sei es nur im Admin-Bereich - anzeigt. Identische Namen werden da zum Problem.
Also halten wir fest: Wenn Namen benutzt werden, dann bitte eindeutige.

Passwörter müssen nicht eindeutig sein, da sie nur in Kombination mit dem Namen geprüft werden und der bereits eindeutig ist.

Mailadressen sollten je nach Konzept eindeutig sein oder nicht. Wenn du zuläßt, dass sich ein Mensch mehrere Accounts anlegt, dann gestatte ihm, diese alle über die selbe Mailadresse laufen zu lassen.
Möchtest du das nicht, kannst du Mehrfachaccounts auch nicht verhindern, aber der Mensch braucht dann soviele Mailadressen wie er Accounts haben will.


So und nun überlege dir einfach mal, was du brauchst, was du bieten möchtest und was dafür nötig ist. Meine Erklärungen sind nämlich nur allgemeiner Natur, je nach Konzept völlig unpassend.

Ich kapiere dass mit den ' den " und den \ noch nicht so richtig, warum ist das hier jetzt falsch???

$user_equal="SELECT
username
FROM
users
WHERE
username = '$_POST['username']' "

Wer sagt, dass das falsch ist? Und was sagt er? Dass ein Semikolon fehlt?

http://www.php-resource.de/forum/showthread.php?threadid=58111

Wenn du PHP-Code postest, nutz auch mal die entsprechenden Tags des Forum!

Die Fehlermeldung sagt das ^^ Also ich habs rausgefunden. Um die ganzen Befehle mache ich keine " " sonder nur ' ' und um den key vom array mache ich keine ' ' sondern gar nicts... Ich habe aber leider nicht verstanden warum das so ist.

Joa das mit dem Semikolon ist AUCH richtig.

WAS ist die Fehlermeldung???

Lies auch mal den Link!

Und unsere Regeln: http://www.php-resource.de/forum/showthread.php?threadid=50454

Zu Fehlermeldung muss ich wieder erklären..... ich habe in meinem Quellcode diese Variable

$user_equal="SELECT
username
FROM
users
WHERE
username = $_POST[username]";


und weiter unten habe ich dann dieses Query

$result_user_equal = mysql_query($user_equal) OR die(mysql_error());

und diese Abfrage

if(mysql_fetch_assoc($result_user_equal))
{
die("Der Username ist leider schon vergeben.<br/>\n
Bitte wählen Sie einen anderen Username.\n");
}


Vielleicht habe ich da vollkommenen Quatsch geschrieben, aber ich musste ja irgendwas ausprobieren. Also habe ich in der Tabelle Users schon mal einen Datensatz angelegt in dem der Username "Lexus_Ks" ist um jetzt testen zu können, was passiert wenn ich versuche mich mit dem gleichen Username anzumelden.... Wenn ich das versuche kommt folgende Fehlermeldung:

Unknown column 'Lexus_ks' in 'where clause'

Aber warum verstehe ich nicht. wenn durch mysql_fetch_assoc einer ressource id welche leer ist ein false kommt, dann müsste doch bei einer besetzten Ressource ID das Gegenteil passieren, oder? Und WENN die Ressource ID Belegt ist, dann steht doch fest, dass der Benutzername schon mal vorhanden ist, weil er ja nur dann rausgesucht wird (durch meine WHERE Bedingung) Also müsste dann der IF Teil abgearbeitet werden -______________-

Habe es jetzt nochmal anstatt mit mysql_fetch_assoc() mit mysql_num_rows() versucht...also dass er den "die"-Teil abarbeitet, wenn eine Zeile ausgelesen wurde (was ja nur der Fall ist wenn der USername schon mal vorhanden ist). Da kommt die gleiche Fehlermeldung.

Habe jetzt rausgefunden, dass das bedeutet, dass es die Spalte 'Lexus_Ks' nicht gibt.... aber das habe ich auch nicht geschrieben, odeR? Ich habe doch geschrieben, dass er einen Datensatz raussuchen soll, WENN EIN WERT der Spalte genauso ist wie der eingegebene Name (in diesem Fall Lexus_ks)

Wird vielleicht bei

$bla='....
WHERE
username = $_POST[username]';


das erste username schon aus dem $_POST gezogen (dementsprechend würde ja dann da stehen "WHERE Lexus_Ks = Lexus_KS" und die Spalte Lexus_Ks gibts natürlich nicht .... !?

Du weißt schon, dass Strings (also z.B. dein Username) in Anführungszeichen (gerne auch einfache) gehören.

Ich hab jetzt nicht alles gelesen.

Aber du hast offensichtlich meine Links auch noch nicht so wirklich gelesen und befolgt.

Ich habe die Fehlermeldung gepostet und den code in tags gesetzt.... was sonst noch????????????????????????????????????????????????????

Deine Tastatur ist defekt. Kein Grund hier motzig zu werden. Ich meine den mit den Strings richtig trennen und die Sache mit dem Error-Reporting.

Sorry werd hier grad emotional.. ^^ Ich bin sauer auf mic hselbst.. weil ichs nich kapier.. Aber Username ist doch gar kein String sondern der NAme der Spalte.

Achso... du meinst den $_POST[username] ^^ Und in welchen Situationen muss ich nur den key in '' schreiben? Also so hier : $_POST['username'] ?

Ich jede ja auch nicht von "Username", sondern von deinem Usernamen. Und der ist ein String und sollte auch als solcher gekennzeichnet werden.

Achso... du meinst den $_POST[username] ja

Und in welchen Situationen muss ich nur den key in '' schreiben? Den Key/Index musst du immer in anführungszeichen schreiben. So wie es in dem genannten Thread steht.

Aber hier habe ich alles in ' ' geschrieben ( '$_POST[username]' ) und es funktioniert... und ich habs jetzt eben schnell ausprobiert: Wenn ich es so schreibe: $_POST['username'] funktioniert es nicht -_-

ja, würdest du die beiden threads mal verinnerlichen...

Ich kapier des nit -___- das is sehr durcheinander :o

Ich merk mir einfach wie ich es das nächste mal konkret an so einer Stelle mache.

Ich habe noch eine Frage..... Wenn ich mehrere Funktionen verschachtel:

Funtkion1(Funktion2(Funktion3($variable)));

Wird dann beim Parsen zuerst die äußerste Klammer abgearbeitet und dann geht PHP nach innen alle Funktionen durch, oder ist es umgekehrt?

natürlich umgekehrt.

hätte ein test auch schnell ergeben.

Also die registrierung samt DB Eintragung funktioniert jetzt. Darf ich sie hier mal posten, damit ihr sie auf evtl. Sicherheitslücken untersucht?

posten darfste gerne.

aber denk an die breite oder knalls in den anhang.

Also habe hier mal die Datei, die mein Formular verarbeitet und in die DB schreibt. Wäre toll wenn ihr mir sagt, was da noch besser gemacht werden könnte und was verbessert werden MUSS (wegen der sicherheit usw).

Danke

PS: Seht mal davon ab, dass in der hochgeladenen Datei noch die Arrayausgabe drin ist ^^

Deine ersten Abfragen hast du nicht gegen SQL Injection abgesichert.

Und bei den Updates nutzt du dann addslashes statt dem (verflixt, wie oft muss man das hier eigentlich noch erzählen?) dafür vorgesehenen mysql_real_escape_string.

Außerdem verunstaltest du die Daten noch vor dem Einfügen in die DB mit htmlspecialchars - ist idR. unsinnig, Daten werden jeweils nur für den aktuellen Kontext behandelt. Und der Kontext "HTML" ist der DB vollkommen wurscht, der kommt erst bei der Ausgabe der Daten ins Spiel.

Deine ersten Abfragen hast du nicht gegen SQL Injection abgesichert.

Okay SQL Injection sagt mir gar nichts, dass ist dann wohl das nächste Thema mit dem ich mich beschäftigen werde...

Und bei den Updates nutzt du dann addslashes statt dem (verflixt, wie oft muss man das hier eigentlich noch erzählen?) dafür vorgesehenen mysql_real_escape_string.

Woher soll ich diese Funktion kennen? Meinst du ich lese mir eine Referenz mit allen Befehlen durch die es gibt? Die lerne ich eben in so Situationen wie dieser hier ^^ Danke

Aber ich habe es ,um mich zu verteidigen, so im PHP Quake Tutorial gelernt. Zuerst Stripslashes() und dann umgekehrt mir addslashes ^^ Wo ist der unterschied zwischen addslashes und mysql_real_escape_string? Benutze ich das auch in Verbindung mit stripslashes?

Außerdem verunstaltest du die Daten noch vor dem Einfügen in die DB mit htmlspecialchars - ist idR. unsinnig, Daten werden jeweils nur für den aktuellen Kontext behandelt. Und der Kontext "HTML" ist der DB vollkommen wurscht, der kommt erst bei der Ausgabe der Daten ins Spiel.

Zitat aus PHP Quake

Doch dies ist so, wie es da steht, eine riesige Sicherheitslücke. Man darf NIE Daten aus der URL oder aus dem Formular direkt in eine Datenbank speichern lassen. Man muss die Eingaben immer prüfen und ggf. bestimmte Zeichen löschen oder bearbeiten. Denn ohne solche Überprüfungen ermöglichen wir Hacker die Möglichkeit für XSS. Deswegen müssen wir einmal die HTML-Zeichen wie < und > umwandeln. Dies machen wir mit htmlspecialchars.

Und ich kansn ja nur so umsetzen wie ichs lerne... Wenn mir jemand erklärt, dass es der Sicherheit nicht wehtut das wegzulassen, dann mach ichs auch, aber ich denke ich tue mir nicht weh dabei und so spare ich es mir doch bei der Ausgabe.

Original geschrieben von Lexus_Ks
Wenn mir jemand erklärt, dass es der Sicherheit nicht wehtut das wegzulassen, dann mach ichs auch, aber ich denke ich tue mir nicht weh dabei und so spare ich es mir doch bei der Ausgabe.
Natürlich ist htmlspecialchars (oder htmlentities, reicht eigentlich aus) wichtig zur Absicherung, damit kein HTML- oder Javascript-Code eingefügt werden kann.
Aber diese Funktionen wendet man idR. bei der Ausgabe an.
Deine Datenbank stört HTML nicht im geringsten, also gibt es kaum einen Grund, es beim Einfügen in diese zu entschärfen. Hat den Vorteil, dass du die Daten in der DB immer noch original vorliegen hast, wenn du sie mal bearbeiten willst - und dich dann nicht mit kodierten Sonderzeichen rumschlagen musst.

Achso meinst du das... klaro *nachdenk* html oder java würde ja erst bei der Ausgabe tätig werden... aber jetzt überlege ich was überwiegt.... entweder das Verlangen danach, die ganze Sache im Original vorliegen zu haben oder etwa die Faulheit.... denn wenn ich es so mache wie du sagst, müsste ich es ja jedes mal einzeln dieser funktion unterziehen (jedesmal wenn ich die datenauslese)... andererseits kann man da ja auch eine Funktion schreiben -.- .. darüber muss ich mir noch einen Kopf machen.

Mir ist grad die Sache mit dem Addslashes und vor allem it dieser SQL Injection wichtiger. Habe mir gerade einen artikel darüber durchgelesen :eek: böse Sache ^^ Aber das dabeistehende Tutorial um sowas zu verhidnern habe ich nicht verstanden. Wenn jemand ein einfaches findet, dann sagt bitte bescheid, umegkehrt gilt das gleiche.

Also ich habe mir überlegt man könnte alle Felder auf bestimmte Kriterien untersuchen um diese SQL Injection zu vermeiden. Ich habe folgedne FeldeR:

Name(max. 20 Zeichen)
Hier könnte man Testen ob der Name nur aus Buchstaben besteht.(Ich denke mal das PHP da standartmäßig einen Befehl hat)

Vorname
Hier auch

Geschlecht
Hier kann man ja nichts machen, weil es input-tags mit dem type "radio2 sind... da kann man schlecht was eingeben.

Geburtsdatum
Besteht aus 3 Feldern.2 Dropdown und 1 Eingabefeld(für das Jahr[max. 4 Zeichen]). Da müsste man ja nur das letzte Feld untersuchen, ob es nur aus Zahlen besteht.(da gibts den ctype_digit()-Befehl)

Username
Hier müsste man überlegen eine eigene Funktion zu entwerfen, welche den String untersucht. Dann müsste man bei der Registrierung dazu schreiben, dass nur Buchstaben, Zahlen, "-" und "_" erlaubt sind..... damit kann man doch nichts machen, oder?

Email
Hier weiß ich auch noch nicht so genau.

Passwort
Dazu schreiben dass es nur aus Buchstaben und Zahlen bestehen darf. Und dann eben eine Funktion zum Prüfen schreiben.

ICQ
Hier kann man wieder den ctype_digit() - Befehl nutzen

MSN
Hier weiß ich noch nicht wie es gehen soll.

Das bin ich
Hier wirds schwierig. Ich fände es blöd dem nutzer zu verbieten, Sonderzeichen zu nutzen.

Meine Interessen
Hier gilt das gleiche

Job
Hier kann man wieder prüfen obs nur Buchstaben sind.

Wohnort
Hier auch.


Ist das soweit in Ordnung?

EDIT:

Ich habe hier in einem Thread davon gelesen einfach alle Strings mit ereg() nach bestimmten Zeichen zu durchsuchen... wäre das besser?

Original geschrieben von Lexus_Ks
Geschlecht
Hier kann man ja nichts machen, weil es input-tags mit dem type "radio2 sind... da kann man schlecht was eingeben.
Irrtum! Ich kann das Formular auch bei mir speichern, ändern und dann abschicken. Denk mal drüber nach.

Zum Prüfen der Formulardaten eignen sich reguläre Ausdrücke sehr gut. Die kann man an zentraler Stelle (Konfig) einmal definieren und muß später nicht am Code fummeln, wenn sich die Kriterien ändern.

Gegen SQL-Injection hilft mysql_real_escape_string() und natürlich sauberes Programmieren. Das heißt, man sollte stets wissen, welchen Typ und Wert jede Variable hat oder annehmen kann. Dazu gehört die wasserdichte Prüfung der EGPCS-Daten vor ihrer Benutzung.

Also mysql_real_escape_string() sagt mir jetzt schon die zweite Person.... ahbe mir den link durchgelesen... aber ich verstehe es nit :o und was heißt EGCPS????

Wie solltest du denn mein Formular von deinem PC aus an meinen Server senden? Dann stimmen doch die ganzen Links nicht mehr, oder?

EGPCS steht für $_ENV, $_GET, $_POST, $_COOKIE und $_SESSION, also so ziemlich alle Wege, auf denen ein PHP-Script Daten von außerhalb bekommen kann. Die Sessiondaten sind natürlich nicht wirklich von außen ...

Zur Manipulation deines Formulars muß nur der action-Parameter der Form passen. Den kann ich auch manipulieren. Alles kann ich manipulieren. Jeder kann das!

Aber um die Prüfung dieser Daten ( in meinem Fall nur die $_POST Daten, weil ich nur diese verwende) geht es doch die ganze Zeit ^^
Und was macht jetzt dieses mysql_real_escape_string() ..... ich habe mir den Text hinter dem Link durchgelesen, aber ich verstehe ihn nicht so richtig -.- Also wie werden diese Zeichen denn maskiert? Muss ich dann auch kein Stripslashes mehr machen??

Was bitte verstehst du denn an
Maskiert spezielle Zeichen innerhalb eines Strings für die Benutzung in einer SQL-Anweisung
Diese Funktion maskiert spezielle Zeichen in unescaped_string, unter Berücksichtigung des aktuellen Zeichensatzes der Verbindung, zur sicheren Benutzung in mysql_query().
Bevor Sie eine Anfrage an MySQL absetzten, müssen Sie immer diese Funktion verwenden (mit einigen Ausnahmen), um Ihre Daten sicher zu machen.
nicht?

Ja woher soll ich wissen wie das maskiert wird? Das steht da nicht -.-
Außerdem kapier ich nicht warum ich das so machen soll -__- ich benutze doch stripslashes wegen diesem magic_quotes ... ich kapier des nit :dontknow:

Brauch ich dann Stripslashes auch nicht mehr wenn ich mysql_real_escape_string nutze?

Ich müsset doc htrotzdem (in der if abfrage (falls dieses magic-quotes an ist)) noch stripslashes benutzen, oder?

Und ich muss doch dieses mysql_real_escape_string müsste ich doch auch wieder rückgängig machen oder????
Zudem müsste ich auch irgendwann das stripslashes mit addslashes rückgängig machen :{ Ich blicke nicht merh durch

Okay, diese Funktion stellt also NULL, \x00, \n, \r, \, ', " und \x1a ein \ voran. Dass heißtr durchaus, dass ich vorher noch (wenn magic_quotes an ist) stripslashes machen muss, aber ich muss kein addslashes machen. Okay danke.... manchmal dauert es ein bisschen, bis ich was peile -.- :D

Aber was ich mich JETZT noch frage ist, ob es sinnvoll ist diesen Befehl in dem Query zu machen oder dies lieber vorher zu erledigen?

Hier, habe jetzt einfach addslashes ersetzt. Muss ich bei den SELECT FROM WHERE Abfragen auch so was machen (gegen SQL Injection)? Sähe es dann so aus:


$user_equal="SELECT
username
FROM
users
WHERE
username = mysql_real_escape_string('$_POST[username]')";


Wäre das richig?

Im Anhang also erstmal wieder die aktuelle Datei :)

... username = '".mysql_real_escape_string(...)."' ...

Es ist eine PHP- keine MySQL-Funktion.

achso ^^

also:


$email_equal="SELECT
email
FROM
users
WHERE
email = '".mysql_real_escape_string($_POST['username'])."' ";

So funktioniert es aber nicht. Jetzt lässt er es zu wenn ich eine emailadresse angebe, die schon registriert ist. das ar davor nicht so.

EDIT:

Lol, ist ja klaro, wenn ich die emailadresse mit dem username vergleiche ^^

Wenn magic_quotes_gpc bei dir immer noch auf on ist, musst du natürlich vorher stripslashes anwenden.

Ist klaro, habe ich auch noch.. wie im Edit meines vorigen Postes gesagt: Wenn ich $_POST['username'] mit der email adresse aus der db vergleiche kann ja keine übereinstimmung kommen ^^ Funktioniert jetzt.

Jetzt werde ich noch einbauen, dass man kein leeres Passwortfeld abgeschickt werden kann (das ist keinem von euch aufgefallen- in der aktuellen version gehts nämlich noch) und dass man eine ICQ Nummer nur einmal nutzen kann...

Wie könnte ich denn emailadressen auf ihre Richtigkeit prüfen?

Ich habe noch ein Problem mit meiner DB. Ich habe als Typ für die Spalte in der die ICQ Nummer gespeichert wird TINYINT(9) angegeben. Leider werden nur 3 Ziffern gespeichert, und zwar jedes mal die gleichen : 127

Jetzt werde ich noch einbauen, dass man kein leeres Passwortfeld abgeschickt werden kann (das ist keinem von euch aufgefallen- in der aktuellen version gehts nämlich noch) Dagegen ist generell ja auch erstmal nichts einzuwenden. Zumindest was die Sicherheit deines Scriptes angeht. ;)

Wie könnte ich denn emailadressen auf ihre Richtigkeit prüfen? Indem du einen der 1.000 Snippets aus dem Internet verwendest. Alternativ einfach auf nen @ prüfen. ;)

Original geschrieben von Lexus_Ks
Ich habe als Typ für die Spalte in der die ICQ Nummer gespeichert wird TINYINT(9) angegeben.
Und was ließ dich auf den Gedanken kommen, dieser Datentyp könnte dafür geeignet sein?
Leider werden nur 3 Ziffern gespeichert, und zwar jedes mal die gleichen : 127
http://dev.mysql.com/doc/refman/4.1/en/numeric-types.html

@TobiaZ

Dagegen ist generell ja auch erstmal nichts einzuwenden. Zumindest was die Sicherheit deines Scriptes angeht.

Joa, von der sicherheit her nicht, aber für den User isses nit so toll, wenn man so einfach da rein kommt ^^

Indem du einen der 1.000 Snippets aus dem Internet verwendest. Alternativ einfach auf nen @ prüfen.

Okay, da werd ich mich dann wohl mal umschauen ^^

@Wahsaga

Und was ließ dich auf den Gedanken kommen, dieser Datentyp könnte dafür geeignet sein?

Ich habe wohl eine 3 Klassige Seite gefunden, auf der der Bereich nicht geschrieben stand, welcher für diesen Typ geeignet ist ^^ Danke

So, es ist mal wiedr so weit... ich finde den verflixten Fehler mal wieder nicht. Ist bestimmt wieder eine Kleinigkeit. Habe die Datei schon ein paar mal durchsucht, aber ich finde das Problem einfach nicht. Die Fehlermeldung die Ausgegeben wird ist:

Parse error: syntax error, unexpected $end in /usr/export/www/vhosts/funnetwork/hosting/dusklounge/include/register_user.inc on line 233

Ich habe noch ein paar Abfragen rein gemacht um die Richtigkeit zu prüfen und so.

Die Datei ist im Anhang.

Alle öffnenden und schließenden Klammern geprüft? Besonders so im Bereich um ICQ herum.

-.- Danke.

Warum ist das manchmal so schlimm? Gibt es nicht ein Program, dass PHP codeschon mal standartmäßg auf fehlende semikolons und ungeschlossene Klammern durchsucht??

Das wäre doch mal eine schöne Aufgabe für jemanden der es drauf hat :D ein Programm zu schreiben, dass alle nach links geöffneten runden und geschweiften klammern und alle nach rechts geöffneten runden und geschweiften Klammern zählt :teach:

Woher soll ein Programm wissen, an welcher Stelle du den Block beendest? Gut möglich, dass die Klammer erst in die Letzte Zeile kommt. Deswegen gibt die Fehlermeldung 233 an.

Bei ; siehts schon anders aus. Das können die meisten IDEs. Such mal im Forum, was es so für Empfehlungen gibt.

Bei ner Vernünftigen Struktur (Einrücken, Klammern immer an der gleichen Stelle, ...) sieht man es aber idr. immer. Du weiß ja, wonach du suchen musst. Und dann brauchst du nur noch am linken Rand gucken, wo da ne } fehlt.