php: Syntax-Error

[flixxgamez]

Hallo, ich bin gerade dabei ein einfaches Login-System zu erstellen. Ich benutze hierzu eine MYSQL-Datenbank per XAMPP. Die anderen Scripte sind in PHP.

Wenn ich die Seite ausprobiere, kommt immer beim Überprüfung der Datei ein Sytax-Error, welcher laut Fehlercode ein Problem mit dem AND hat (gleiches Problem mit &&): Parse error: syntax error, unexpected 'AND' (T_LOGICAL_AND) in C:\xampp\htdocs\Login\confirm.php on line 16

Hier ist der PHP-Code, welcher den Form-Input überprüft:

<?php
    $username = $_POST['username'];
    $password = $_POST['password'];

    $username = stripcslashes($username);
    $password = stripcslashes($password);
    $username = mysql_real_escape_string($username);
    $password = myswl_real_escape_string($password);

    mysql_connect("localhost", "root", "");
    mysql_select_db("anmeldung");

    $result = mysql_querry("select * from login where benutzername = '$username' and passwort = '$password'")
        or die("Faied");
    $row = mysql_fetch_array($result);
    if ($row['username'] == $username) AND $row['password'] $password) {
        echo = "Login fertiggestellt! Hallo" .$row['username'];
        }
    else {
        echo = "Login fehlgeschlagen"
    }
?>

[Robert B.]

Moin,

was steht denn in Zeile 16 in der Nähe des AND?

Viele Grüße
Robert

[MudGuard]

Hi,

$username = stripcslashes($username);
$password = stripcslashes($password);

stripcslashes?

magic quotes sind doch seit Jahren tot ...

$username = mysql_real_escape_string($username);
$password = myswl_real_escape_string($password);

myswl?

mysql_connect("localhost", "root", "");
mysql_select_db("anmeldung");

$result = mysql_querry("select * from login where benutzername = '$username' and passwort = '$password'")

mysql_querry?

select * sollte man auch nicht benutzen.

Und vor allem: Du speicherst Paßwörter im Original in der DB?

Üblicherweise speichert man nur einen Hash des Paßworts. Und berechnet vom angegebenen Paßwort mit demselben Hash-Algorithmus den Hash und vergleicht dann die Hashes.

cu,
Andreas a/k/a MudGuard

[flixxgamez]

Hey, komischer Weise hat er da keine Fehler angezeigt...

Aber danke für die Tipps und Hinweise

[dedlfix]

Tach!

komischer Weise hat er da keine Fehler angezeigt...

Komischerweise ist ein Wort. Die Fehler bei den Funktionsnamen erkennt der Parser nicht, das sind keine Syntaxfehler. Sie werden erst zur Laufzeit entdeckt, wenn die Funktion nicht gefunden wird. PHP ist ja dynamisch, und Funktionen können auch erst zur Laufzeit hinzugefügt werden, weswegen der Parser da nichts vor dem Lauf prüfen kann. Du hättest die Fehler noch zu Gesicht bekommen, nach der Reperatur des if.

dedlfix.

[Der Martin]

Moin,

Die Fehler bei den Funktionsnamen erkennt der Parser nicht, das sind keine Syntaxfehler. Sie werden erst zur Laufzeit entdeckt, wenn die Funktion nicht gefunden wird. PHP ist ja dynamisch, und Funktionen können auch erst zur Laufzeit hinzugefügt werden, weswegen der Parser da nichts vor dem Lauf prüfen kann. Du hättest die Fehler noch zu Gesicht bekommen, nach der Reperatur des if.

außerdem bricht der PHP-Parser beim erstbesten Syntaxfehler ab und beschwert sich, eventuelle weitere Syntaxfehler werden also erst angezeigt, wenn der erste behoben ist.

Das ist anders als bei einem typischen C-Compiler, der erstmal weitermacht und in einem Compilerlauf eine ganze Reihe von Fehlern anzeigt - im günstigsten Fall sogar alle, die formal erkennbar sind.

Live long and pros healthy,
 Martin

[dedlfix]

Tach!

Wenn ich die Seite ausprobiere, kommt immer beim Überprüfung der Datei ein Sytax-Error, welcher laut Fehlercode ein Problem mit dem AND hat (gleiches Problem mit &&): Parse error: syntax error, unexpected 'AND' (T_LOGICAL_AND) in C:\xampp\htdocs\Login\confirm.php on line 16

Das AND steht außerhalb der Klammern von if. Wenn du mehrere Bedingungen angeben möchtest, und diese einzeln klammern möchtest, dann musst du ein weiteres Klammernpaar außen drumherum setzen. Aber du brauchst deine Einzelausdrücke nicht zu klammern, laut Operator Precedence werden die beiden Vergleiche vor der AND-Verknüpfung ausgewertet.

Deine PHP-Version oder dein Tutorial scheint uralt zu sein, die mysql-Funktionen gibt es nicht mehr. Sie wurden abgelöst durch mysqli, aber besser ist PDO, weil verwenderfreundlicher.

dedlfix.

[Rolf B]

Hallo dedlfix,

es ist vor allem gar nicht nötig, nach der SQL Abfrage nochmals die Werte zu vergleichen. Das hat MYSQL schon getan.

Wenn man mysqli verwendet, dann liefert mysqli_query(...) ein mysqli_result Objekt. Darauf gibt's ein num_rows Property, das muss man nur abfragen.

Die Datenbank kann man auch gleich beim Erzeugen des DB-Objekts mitgeben, 4. Parameter. Man muss bei der Objekt-Syntax nur connect_error abfragen, weil man immer ein Objekt bekommt.

$db = mysqli_connect("localhost", "root", "", "anmeldung");
if ($db === FALSE) {
   // DB nicht verfügbar, Error Handling. mysqli_connect_error() liefert den Grund
}
$result = mysqli_query($db, "SELECT username FROM login" .
                           " WHERE benutzername='$username'" . 
                           " AND passhash='$hashedPassword'");

$result ist im Falle eines SQL Fehlers FALSE, andernfalls ein mysqli_result Objekt. Das kann man mit Funktionsaufruf oder direkt befragen. Das Query-Ergebnis ist egal - es sei denn, man muss noch mehr Daten aus der login-Tabelle laden.

    if ($result !== FALSE && $result->num_rows > 0) {
        echo = "Login fertiggestellt! Hallo $username";
    }
    else {
        echo = "Login fehlgeschlagen"
    }
}

Lektüre zu mysqli

Rolf

[Raketenwissenschaftler]

AND passhash='$hashedPassword'

Ist ein schlechtes Beispiel.

Das Password sollte in PHP mit password_hash( $password ) gehasht werden. Das bedeutet, es wird mit salt gehasht. also holt man den Hash aus der Datenbank und vergleicht danach mit passwort_verify( $password, $hash ). Ist diese Überprüfung erfolgreich testet man außerdem sofort mit password_needs_rehash( $hash ). Wenn das Password neu gehasht werden sollte, dann tut man genaus das mit password_hash( $password ) und schreibt den neuen Hash in die Datenbank. Das könnte zum Beispiel nach einem Update von PHP "feuern".

[flixxgamez]

Hey, habe mir gestern ein Tutorial angeschaut und mir fällt das was du im letzen Satz sagst jetzt auch auf 🙄.

Jetzt weiß ich, dass man wohl bei PHP auch auf das Datum schauen soll.

Danke

[Raketenhandbuchschreiber]

Hey, habe mir gestern ein Tutorial angeschaut

Hoffentlich nicht bei Youtube…

https://code.fastix.org/Projekte/PHP%3Alogin-system/

• Vom 8. Juli 2019.
• Speichert aber in Textdateien.
• Das PDF kann als Tutorial dienen, wie man sowas schreibt.

[1unitedpower]

https://code.fastix.org/Projekte/PHP%3Alogin-system/

@flixxgamez lass die Finger von diesem Skript. Ich habe die Probleme damit schon öfter hier aufgeschrieben, zuletzt hier.

[Raketenhandbuchschreiber]

@1unitedpower

Auch auf die Gefeahr hin, dass Du wieder austickst (und mir ist auch echt egal wer das „gut findet“, denn das disqualifiziert jenden einzelnen von diesen selbst.

Deine „Kritik“ offenbart erhebliche Schwächen:

Du schreibst z.B. in Deiner „Kritik“:

Das Login-System benutzt die selben Konfigurations-Dateien, wie der Apache-Webserver für die Benutzer-Authentifizierung.

Das ist schon mal erweislich sachlich falsch. Und zwar aus drei (sic:3) Gründen:

1. Denn beim Apache muss die Datei mit den Benutzernamen und Passwörtern konfiguriert werden - und zwar so:

AuthType Basic
AuthName "Passwortgeschützter Bereich"
AuthUserFile /pfad/zur/datei/.htpasswd
Require valid-user

Es gibt dafür auch keinen Default.

2. Auch in meinem Skript ist der Dateiname (und Pfad) zu konfigurieren.

3. Und dann schauen wir mal in das PDF, Seite 10:

Es kann nämlich auch ein „goldrichtig“ sein, dass genau so zu machen, weil meine Dateien kompatibel zu dem sind, was der Apache erwartet - anders ausgedrückt kann man die Benutzerverwaltun also dual nutzen.

Wenn Dir das nicht eingeht, dann solltest möglicherweise in Betracht ziehen, dass Du beim Nachdenken nicht tief genug vorgedrungen bist.

Anders ausgedrückt, Du trägst objektiv „nicht ganz korrekt“ vor (1.) und (2.) übergehst die zugehörige Dokumentation.

Der Rest deiner Kritik folgt diesem Schema und ich habe keinen Bock, Deinen Mist noch weiter aufzulösen.

Da Du stur an diesem unrichtigen Vorgehen fest hältst und Dir auch persönlichen Ausfälligkeiten nicht verkneifen kannst, verbitte ich mir, dass Du auf meine Antworten reagierst. Ich reagiere auf Deine Beiträge allenfalls das auch nur auch um zu bestätigen bzw. zu ergänzen und halte aber schön brav die Schnauze, wenn Du unrichtiges oder gar bedenkliches schreibst.

Ich kann das auch gerne ändern.

[Matthias Apsel]

Hallo Raketenhandbuchschreiber,

Anders ausgedrückt, Du trägst objektiv „nicht ganz korrekt“ vor (1.) und (2.) übergehst die zugehörige Dokumentation.

Möglicherweise gabs die 2019 auch noch nicht und du hast in der Zwischenzeit nachgebessert (was eher ein Lob denn ein Vorwurf ist).

Da Du stur an diesem unrichtigen Vorgehen fest hältst und Dir auch persönlichen Ausfälligkeiten nicht verkneifen kannst, verbitte ich mir, dass Du auf meine Antworten reagierst. Ich reagiere auf Deine Beiträge allenfalls das auch nur auch um zu bestätigen bzw. zu ergänzen und halte aber schön brav die Schnauze, wenn Du unrichtiges oder gar bedenkliches schreibst.

Mir ist ebenfalls nicht an einem Streit gelegen, der das Potenzial hat, nur wenig bis gar nicht konstruktiv zu sein. Und ich wüsste auch nicht, wo man da einen Kompromiss erzielen möchte. Ich schlage deshalb vor, dass ihr beide die Diskussion nicht wieder neu eröffnet. Fakt ist, dass selbstgestrickte sicherheitssensible Lösungen große Gefahren in sich bergen, wie du an anderen Stellen nicht müde wirst zu erwähnen.

Bis demnächst
Matthias

[Raketenhandbuchschreiber]

Fakt ist, dass selbstgestrickte sicherheitssensible Lösungen große Gefahren in sich bergen,

Man kann, ungenügendes Wissen, grobe Fahrlässigkeit oder Böswilligkeit vorausgesetzt, jede beliebige - also auch fremdgestrickte sicherheitssensible Lösungen so einsetzen, dass man „Montags in der Zeitung steht“. Der Beweis dafür steht geradezu regelmäßig bei heise.de auf der Startseite.

Das ist ja auch meine Kritik an der „Kritik“ von 1UP. Der bezieht sich gar nicht wirklich auf mein Zeug, sondern konstruiert höchst mutwillig Umstände - die aber gar nicht nur für mein Zeug gelten.

Nehmen wird das oben: Man kann z.B. mit jeder Auth-Lösung, die auf Dateien basiert, z.B. eine Konkurrenzsituation zu anderen Skripten bauen. Vorliegend kann es - aus nahe liegenden Gründen - z.B. der Erzeugung der ersten Datei mit dem Verwalterpasswort - nicht der Job meines Skriptes sein zu untersuchen, ob womöglich irgend etwas anderes eine zu konfigurierende Datei mit benutzt. Das ist Sache des Verwalters, also desjenigen, der die Konfigurationsdatei zu bearbeiten hat. Zur Kritik von 1UP, dass meine Skripte ja auch mit http funktionieren würden, habe ich anderweitig schon ausgeführt - das ist genau die gleiche Chose, denn das ist Sache der Serverkonfiguration, nicht aber der PHP-Skripte. Will man sich in diesen „gegen alles“ absichern, dann bekommt man Performanceprobleme hoch 3 - und mit Verlaub nehmen auch die hoch gelobten Bibliotheken mit breiter Unterstützung genau diese Prüfung ganz gewiss nicht sämtlich (falls es überhaupt eine im PHP-Teil tut) vor.

[Raketenhandbuchschreiber]

Das Skript funktioniert sowohl mit HTTPS als auch mit unverschlüsseltem HTTP.

Wenn ich sowas lese, dann bin ich mir im Zweifel, ob derjenige, der sowas schreibt, überhaupt noch sachlich vortragen - oder nur sachlich klingen will.

Denn das obige ist nicht Job eines PHP-Skriptes, sondern der Serverkonfiguration:

1.) https://cwiki.apache.org/confluence/display/HTTPD/RedirectSSL

2.) https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html

Soll ich weiter machen?

[Matthias Apsel]

Hallo Raketenhandbuchschreiber,

Soll ich weiter machen?

Hattest du nicht grade eben noch angekündigt, keine neue Diskussion vom Zau[m|n] brechen zu wollen?

Bis demnächst
Matthias

[Raketenhandbuchschreiber]

Hattest du nicht grade eben noch angekündigt, keine neue Diskussion vom Zau[m|n] brechen zu wollen?

Nun, nur Punkt 1 zu widerlegen hätte den Geruch des Zufalls gehabt. Wenn aber auch noch der unmittelbar folgende Punkt 2 genau so leicht aufzeigbar ebenso die Merkmale völlig willkürlicher und unzutreffender Kritik aufweist, dann wird aus dem „Geruch des Zufalls“ ein recht intensiver solcher - und zwar der, dass es dem „Kritiker“ gar nicht um die Sache geht.

Manchmal tut man das Notwendige, also nicht unbedingt das was man selbst vorhat.

[Matthias Apsel]

Hallo Matthias Apsel,

Diskussion vom Zau[m|n] brechen

So. Hoffentlich werde ich mir das jetzt merken: einen Streit vom Zaun brechen, aber die Streithähne im Zaum halten.

Bis demnächst
Matthias

[Raketenhandbuchleser]

Das wird kaum noch irgendwo funktionieren, auch nicht, wenn Du Deinem XAMPP endlich - nach Jahren - mal ein Update verpasst.

Und hol Dir gleich ein neues Buch für PHP 7.