Frage zu Loginsystem und Benutzerregistrierung mit PHP und MySQL

[Sasser]

[Anmerkung: Die folgende Frage bezieht sich auf den Wiki-Artikel Loginsystem und Benutzerregistrierung mit PHP und MySQL]

Passwort nicht akzeptiert

Registrierung funktioniert, Login leider nicht. Ist der Benutzername falsch, kommt: 'Der Benutzer wurde nicht gefunden.' Ist das Kennwort falsch, kommt: 'Das Kennwort ist nicht korrekt.' (Verbindung zur DB funktioniert also)

Wenn aber das richtige Kennwort eingegeben wird (habe das selbstvergebene, wie auch das kryptische PW bei verschiedenen Benutzern probiert), kommt ebenfalls 'Das Kennwort ist nicht korrekt.'

Wie kommt dieser Fehler zustande? Hat da jemand eine Idee? Hängt das eventuell mit der Session zusammen?

[Auge]

Hallo

Passwort nicht akzeptiert

Das kein Satzz *scnr*

Registrierung funktioniert, Login leider nicht. Ist der Benutzername falsch, kommt: 'Der Benutzer wurde nicht gefunden.' Ist das Kennwort falsch, kommt: 'Das Kennwort ist nicht korrekt.'

Schön. Das sind aussagekräftige Meldungen.

(Verbindung zur DB funktioniert also)

Das schließt du woraus?

Wenn aber das richtige Kennwort eingegeben wird (habe das selbstvergebene, wie auch das kryptische PW bei verschiedenen Benutzern probiert), kommt ebenfalls 'Das Kennwort ist nicht korrekt.'

Wie kommt dieser Fehler zustande? Hat da jemand eine Idee? Hängt das eventuell mit der Session zusammen?

Ohne die Kenntnis des Codes wird dir diese Frage niemand beantworten können. Du sagst ja nicht ein mal, um welche Software es geht.

Um Johnny Nr.5 zu zitieren: „Mehr Input!“

Tschö, Auge

[Jörg Reinholz]

Moin!

Ohne die Kenntnis des Codes wird dir diese Frage niemand beantworten können. Du sagst ja nicht ein mal, um welche Software es geht.

Die Kristallkugel sagt: Klicken Sie hier um im Artikel über "Loginsystem und Benutzerregistrierung mit PHP und MySQL" mehr über "Loginsystem und Benutzerregistrierung mit PHP und MySQL" zu erfahren.

Jörg Reinholz

[Sasser]

Hallo

Passwort nicht akzeptiert

Das kein Satzz *scnr*

richtig, das ist eine Überschrift :)

Registrierung funktioniert, Login leider nicht. Ist der Benutzername falsch, kommt: 'Der Benutzer wurde nicht gefunden.' Ist das Kennwort falsch, kommt: 'Das Kennwort ist nicht korrekt.'

Schön. Das sind aussagekräftige Meldungen.

(Verbindung zur DB funktioniert also)

Das schließt du woraus?

In Verbindung mit meinem Klammerausdruck machen die Meldungen schon Sinn, denke ich. Dass die Datenbankverbindung steht, erkenne ich an den unterschiedlichen Fehlermeldungen, die nur ausgegeben werden können, wenn tatsächlich eine Abfrage in der Datenbank stattgefunden hat.

Wenn aber das richtige Kennwort eingegeben wird (habe das selbstvergebene, wie auch das kryptische PW bei verschiedenen Benutzern probiert), kommt ebenfalls 'Das Kennwort ist nicht korrekt.'

Wie kommt dieser Fehler zustande? Hat da jemand eine Idee? Hängt das eventuell mit der Session zusammen?

Ohne die Kenntnis des Codes wird dir diese Frage niemand beantworten können. Du sagst ja nicht ein mal, um welche Software es geht.

Welche Software ist denn hier relevant? Habe die Dateien erstellt, mit entsprechenden Codes gefüllt und lediglich die Verbindungsdaten zur DB eingetragen.

Den Code habe ich nicht verändert. Alle Dateien sind mit dem ursprünglichen Code, wie er hier zu finden ist, gefüllt. Sonst hätte es natürlich explizit angesprochen, dass ich etwas verändert habe.

Um Johnny Nr.5 zu zitieren: „Mehr Input!“

Tschö, Auge

[Camping_RIDER]

Aloha ;)

Welche Software ist denn hier relevant? Habe die Dateien erstellt, mit entsprechenden Codes gefüllt und lediglich die Verbindungsdaten zur DB eingetragen.

Den Code habe ich nicht verändert. Alle Dateien sind mit dem ursprünglichen Code, wie er hier zu finden ist, gefüllt. Sonst hätte es natürlich explizit angesprochen, dass ich etwas verändert habe.

Stichwort "Der Code" ;) Aber denk dir nichts dabei, der Fehler liegt in dem Fall nicht bei dir. Wir sind es nur noch nicht gewohnt, dass Fragen direkt aus dem Wiki kommen und @Auge war (genauso wie mir im ersten Moment) der Zusammenhang nicht klar. Wir arbeiten daran, das deutlicher zu machen :)

Um weitere Nachfragen und Irritationen zu vermeiden füge ich den Link zum Artikel in dein Eröffnungsposting ein.

Grüße,

RIDER

[Sasser]

Kein Problem. Bin für jeden Hilfeversuch dankbar :) Schön zu sehen, dass die Community so lebendig ist.

[Camping_RIDER]

Aloha ;)

Ohne die Kenntnis des Codes wird dir diese Frage niemand beantworten können. Du sagst ja nicht ein mal, um welche Software es geht.

Um Johnny Nr.5 zu zitieren: „Mehr Input!“

Da kann der TO da nichts dafür. Das "Frage zu ..." ist der Standardbetreff, wenn man aus einem Wiki-Artikel heraus ins Forum gelangt. Er wird sich also auf den entsprechenden Artikel, den Jörg ja schon verlinkt hat, beziehen.

Frage @Matthias Apsel: Können wir den automatischen Betreff noch eindeutiger machen, damit im Forum sofort klar wird, dass auf einen Wikiartikel Bezug genommen wird? Zum Beispiel: "Frage zum Wiki-Artikel ..."? Vielleicht auch den Wiki-Artikel direkt als problematische Seite mit angeben? - Ich weiß, das label "problematische Seite" passt in diesem Fall nicht, aber besser als nix isses.

Grüße,

RIDER

---

Und noch was ganz Off-Topic-es @Matthias Apsel​​: Hast du den Beschluss der Mitgliederversammlung zum Bezeichnung des Wiki in der Hauptnavigation noch auf dem Schirm? Oder wird das im Zuge der "Unifizierung der globalen Navigationsleisten" von @1unitedpower übernommen? Nur, dass das nicht in Vergessenheit gerät...

[Auge]

Hallo

Aloha ;)

Oder so …

Ohne die Kenntnis des Codes wird dir diese Frage niemand beantworten können. Du sagst ja nicht ein mal, um welche Software es geht.

Da kann der TO da nichts dafür. Das "Frage zu ..." ist der Standardbetreff, wenn man aus einem Wiki-Artikel heraus ins Forum gelangt. Er wird sich also auf den entsprechenden Artikel, den Jörg ja schon verlinkt hat, beziehen.

Das sieht so aus.

Frage @Matthias Apsel: Können wir den automatischen Betreff noch eindeutiger machen, damit im Forum sofort klar wird, dass auf einen Wikiartikel Bezug genommen wird? Zum Beispiel: "Frage zum Wiki-Artikel ..."? Vielleicht auch den Wiki-Artikel direkt als problematische Seite mit angeben? - Ich weiß, das label "problematische Seite" passt in diesem Fall nicht, aber besser als nix isses.

@Christian Kruse, @Matthias Apsel, @dedlfix: Kann man automatisch einen Tag vergeben, der nicht vom Benutzer entfernt werden kann? Den können wir ja festlegen, z.B. (Achtung: sperrig!) „selfhtml-doku-artikel“, achja, nee (s.u. ;-)) „selfhtml-wiki-artikel“.

---

Und noch was ganz Off-Topic-es @Matthias Apsel​​: Hast du den Beschluss der Mitgliederversammlung zum Bezeichnung des Wiki in der Hauptnavigation noch auf dem Schirm?

Ich habe diesen Beschluss schon wahrgenommen und habe ihn, da ich ja nicht da war, auch nicht zu kommentieren. Ich frage mich aber, warum diese Frage überhaupt aufkam.

Tschö, Auge

[Camping_RIDER]

Aloha ;)

Und noch was ganz Off-Topic-es @Matthias Apsel​​: Hast du den Beschluss der Mitgliederversammlung zum Bezeichnung des Wiki in der Hauptnavigation noch auf dem Schirm?

Ich habe diesen Beschluss schon wahrgenommen und habe ihn, da ich ja nicht da war, auch nicht zu kommentieren. Ich frage mich aber, warum diese Frage überhaupt aufkam.

Wir haben auf der Mitgliederversammlung die gesamte Gestaltung der Kopfzeilen in Wiki und Forum überdacht und diskutiert. In diesem Zug kam dann auch die Frage der Bezeichnung auf. Grund für den Beschluss war u.A. der Sprachgebrauch, da sich die Bezeichnung Wiki im Sprachgebrauch zwischenzeitlich durchgesetzt hat und deutlich häufiger genutzt wird als die Bezeichnung "Doku".

Grüße,

RIDER

[Matthias Apsel]

Hallo Auge,

@Christian Kruse, @Matthias Apsel, @dedlfix: Kann man automatisch einen Tag vergeben, der nicht vom Benutzer entfernt werden kann? Den können wir ja festlegen, z.B. (Achtung: sperrig!) „selfhtml-doku-artikel“, achja, nee (s.u. ;-)) „selfhtml-wiki-artikel“.

Derzeit nein, aber vielleicht ist das auch garnicht sinnvoll? Das Nicht-Entfernen-Können. Das Tag könnte ja "Wiki-Frage" heißen oder "Frage zum Wiki".

Bis demnächst
Matthias

[Camping_RIDER]

Aloha ;)

Derzeit nein, aber vielleicht ist das auch garnicht sinnvoll? Das Nicht-Entfernen-Können. Das Tag könnte ja "Wiki-Frage" heißen oder "Frage zum Wiki".

Erstellt. Du müsstest das dann noch im Wiki in die Vorlage bzw. den Link einfügen.

Grüße,

RIDER

[Matthias Apsel]

Hallo Matthias Apsel,

@Christian Kruse, @Matthias Apsel, @dedlfix: Kann man automatisch einen Tag vergeben, der nicht vom Benutzer entfernt werden kann? Den können wir ja festlegen, z.B. (Achtung: sperrig!) „selfhtml-doku-artikel“, achja, nee (s.u. ;-)) „selfhtml-wiki-artikel“.

Derzeit nein, aber vielleicht ist das auch garnicht sinnvoll? Das Nicht-Entfernen-Können. Das Tag könnte ja "Wiki-Frage" heißen oder "Frage zum Wiki".

@Auge Je mehr ich drüber nachdenke, um so besser finde ich deine Idee. Ich würde sogar noch weitergehen. Wenn jemand direkt aus dem Wiki kommt, soll er

• Betreff und problematische Seite nicht ändern dürfen
• keine Tags entfernen können

Bis demnächst
Matthias

[Camping_RIDER]

Aloha ;)

@Auge Je mehr ich drüber nachdenke, um so besser finde ich deine Idee. Ich würde sogar noch weitergehen. Wenn jemand direkt aus dem Wiki kommt, soll er

• Betreff und problematische Seite nicht ändern dürfen
• keine Tags entfernen können

Ich weiß nicht, das sind schon Einschränkungen. Vielleicht möchte man den Betreff präzisieren bzw. an die konkrete Frage anpassen. Beim Tags entfernen gehe ich noch mit, zumindest inhaltlich, problematische Seite wegen mir auch (wenn man je noch eine andere Seite, z.B. mit der persönlichen Umsetzung, verlinken will, kann man das ja im Fließtext tun). Trotzdem meh.

Ich frage mich auch, ob der Nutzen den technischen Aufwand rechtfertigt.

Oder ob es überhaupt gut wäre, sowas zu tun.

Wenn jemand Tags entfernt oder den Betreff ändert wird er Gründe haben das zu tun - und die sind ihm immerhin wichtig genug, dass er die entsprechenden Schalter betätigt.

Meines Erachtens nach ist die Voreinstellung vorgegebener Tags/Problemseite/Betreff vollkommen ausreichend. Ein Blockieren halte ich hier mehr für eine (eigentlich grundlose) Gängelung des Users. Warum sollten wir User, die ihre Frage nicht einfach so im leeren Raum formulieren (das Forum öffnen und einen neuen Thread eröffnen), sondern schon direkt zielgerichtet fragen in solche Einschränkungen zwingen? Das ist für mich nicht plausibel.

Grüße,

RIDER

[Auge]

Hallo

@Christian Kruse, @Matthias Apsel, @dedlfix: Kann man automatisch einen Tag vergeben, der nicht vom Benutzer entfernt werden kann? Den können wir ja festlegen, z.B. (Achtung: sperrig!) „selfhtml-doku-artikel“, achja, nee (s.u. ;-)) „selfhtml-wiki-artikel“.

Derzeit nein, aber vielleicht ist das auch garnicht sinnvoll? Das Nicht-Entfernen-Können. Das Tag könnte ja "Wiki-Frage" heißen oder "Frage zum Wiki".

@Auge Je mehr ich drüber nachdenke, um so besser finde ich deine Idee. Ich würde sogar noch weitergehen. Wenn jemand direkt aus dem Wiki kommt, soll er

• Betreff und problematische Seite nicht ändern dürfen

Bezüglich des Links zur problematischen Seite stimme ich dir zu. Der Betreff sollte aber änderbar bleiben.

• keine Tags entfernen können

Nöö, das haut nicht hin. Den einen Tag, der alle darauf hinweist, dass es sich um eine Frage zu einem Wiki-Eintrag handelt, würde auch ich sperren. Der Benutzer hat aber die Möglichkeit, zwei weitere Tags zu vergeben. Die soll er mMn vergeben und auch wieder löschen können, schließlich ist er als der Fragende derjenige, der mit den weiteren Tags die Einordnung konkretisieren kann.

Tschö, Auge

[Matthias Apsel]

Hallo Auge,

Frage @Matthias Apsel: Können wir den automatischen Betreff noch eindeutiger machen,

Vielleicht auch den Wiki-Artikel direkt als problematische Seite mit angeben?

Kann man automatisch einen Tag vergeben […]?

Es sieht jetzt beispielhaft so aus:

Betreff:

Frage zum Wikiartikel ‚@-Regeln‘

problematische Seite:

https://wiki.selfhtml.org/wiki/CSS/%40-Regeln

Tags:

css, frage zum wiki

Dass die problematische Seite genau wie der Betreff im Antwortformular vorgeschlagen wird, habe bei github als Issue hinterlegt.

Bis demnächst
Matthias

[Matthias Apsel]

Hallo Camping_RIDER,

Frage @Matthias Apsel: Können wir den automatischen Betreff noch eindeutiger machen, damit im Forum sofort klar wird, dass auf einen Wikiartikel Bezug genommen wird? Zum Beispiel: "Frage zum Wiki-Artikel ..."? Vielleicht auch den Wiki-Artikel direkt als problematische Seite mit angeben? - Ich weiß, das label "problematische Seite" passt in diesem Fall nicht, aber besser als nix isses.

Klar. Mach ich. Gute Idee.

Und noch was ganz Off-Topic-es @Matthias Apsel​​: Hast du den Beschluss der Mitgliederversammlung zum Bezeichnung des Wiki in der Hauptnavigation noch auf dem Schirm? Oder wird das im Zuge der "Unifizierung der globalen Navigationsleisten" von @1unitedpower übernommen? Nur, dass das nicht in Vergessenheit gerät...

Im Wiki ist es schon, Hauptseite, Impressum, Fehlerseiten ist deine Aufgabe :), am Forum wird derzeit heftigst geschraubt, Blog mach ich.

Bis demnächst
Matthias

[Camping_RIDER]

Aloha ;)

Hauptseite, Impressum, Fehlerseiten ist deine Aufgabe :)

Kraft meiner schier unstoppbaren Editiermacht...

Hauptseite   [x] done
Impressum    [x] done
Fehlerseiten [x] done

Grüße,

RIDER

[Matthias Apsel]

Hallo Camping_RIDER,

Hauptseite   [x] done

Das mit dem h4 sieht so nicht so gut aus. Wegens der unterschiedlichen Monitore und Zoomfaktoren.

h4.inlineheading {
  float: left;
  margin: 0;
}

.inlineheading + p::before {
  content: "\00a0"; 
  font-family: oswald, serif;
}

Dann klappts auch mit der Bündigkeit.

Bis demnächst
Matthias

[Camping_RIDER]

Aloha ;)

Dann klappts auch mit der Bündigkeit.

Erledigt. Und im Nachhinein ist mir auch klar, warum die Bündigkeit bei display:inline-block kaputtgeht und dass ich das bei float ja gar nicht brauche ;)

Grüße,

RIDER

[Matthias Apsel]

Hallo Camping_RIDER,

Erledigt. Und im Nachhinein ist mir auch klar, warum die Bündigkeit bei display:inline-block kaputtgeht und dass ich das bei float ja gar nicht brauche ;)

Das funktioniert allerdings nur, weil h4 und p dieselbe Schriftgröße haben. Eventuell sollte man zur Sicherheit noch beiden
aus font-family: oswald, serif;
font: 1em oswald, serif; machen.

Und dabei kannst du dann auch gleich die Jahreszahl in der Fußzeile ändern.

Bis demnächst
Matthias

[Camping_RIDER]

Aloha ;)

Das funktioniert allerdings nur, weil h4 und p dieselbe Schriftgröße haben. Eventuell sollte man zur Sicherheit noch beiden
aus font-family: oswald, serif;
font: 1em oswald, serif; machen.

Und dabei kannst du dann auch gleich die Jahreszahl in der Fußzeile ändern.

"dabei" ist gut, das sind ganz andere repositories ;)

Naja, jedenfalls ist das jetzt auch eingefügt (genau wie das was noch per PN kam). Die Fehlerseite ist jetzt auch aktualisiert (und ihre Kumpanen ebenso). Hoffentlich zur Zufriedenheit ;)

Es hat Stunden gedauert rauszufinden, wo die Fehlerseiten liegen, ich hab egal wo ich geschaut hab nur alte von anno dazumal gefunden. Nochmal Danke an @dedlfix für unsere Session gestern, ohne die Erklärung gestern hätte ich es nie (raus-)gefunden; und ohne das trac-Wiki hätte ich auch nicht mehr gewusst, wie ich den puppet in die richtige Richtung schubsen muss ;)

Hatte auf jeden Fall einen deutlichen Lerneffekt ;)

Grüße,

RIDER

@edit @dedlfix P.S.: Uuund ich hab endlich rausgefunden, wie ich mit giteye effizient den current-Tag hin und herschieben kann ohne Probleme zu bekommen - ist echt einfacher jetzt ;)

[Jörg Reinholz]

Moin!

[Anmerkung: Die folgende Frage bezieht sich auf den Wiki-Artikel Loginsystem und Benutzerregistrierung mit PHP und MySQL]

Passwort nicht akzeptiert

Das kann Ursachen haben, die wir nicht so einfach erkennen können. Z.B. könnte Deine PHP-Version recht alt sein und nicht alles unterstützen.

Hättest Du deshalb die Freundlichkeit, uns hinsichtlich der PHP-Version zu informieren und außerdem in der Datei login.php die ersten Zeilen um ein error-Reporting zu ergänzen?

<?php
error_reporting(E_ALL);
if (isset($_SESSION['login'])) {

Und könntest Du uns bitte zeigen, was bei der Registrierung in der Datenbank landet, insbesondere in den Spalten 'username' und 'password'?

Jörg Reinholz

[Sasser]

[TUFO (?) entfernt]

Ich hab die Zeile eingefügt und den Login erneut probiert, es wird allerdings immernoch kein Fehler angezeigt (außer der, dass das Kennwort nicht stimmt, obwohl es in Wahrheit doch stimmt).

Bei der Registrierung landet immer ein kryptisches PW in der DB (Bsp: $2a$10$XtLQOU91xzqedN...)

Es greift übrigens auch die Fehlermeldung, dass der Benutzer bereits in der DB existiert, wenn dem so ist (falls das irgendwie relevant ist)

[Jörg Reinholz]

Moin!

Bei der Registrierung landet immer ein kryptisches PW in der DB (Bsp: $2a$10$XtLQOU91xzqedN...)

Das ist richtig.

Zeige uns bitte nach Ergänzen und Ausführen der Login.php:

crypt($_POST['f']['password'], $row['password']) == $row['password']; # bleibt stehen
# ergänzt durch:
echo "Eingabe         : '", $_POST['f']['password'], "'</br>";
echo "Hash der Eingabe: '", crypt($_POST['f']['password'], $row['password']), "'</br>";
echo "gespeichert     : '", $row['password'], "'</br>";
exit;

Jörg Reinholz

[Sasser]

Moin!

Bei der Registrierung landet immer ein kryptisches PW in der DB (Bsp: $2a$10$XtLQOU91xzqedN...)

Das ist richtig.

Zeige uns bitte nach Ergänzen und Ausführen der Login.php:

crypt($_POST['f']['password'], $row['password']) == $row['password']; # bleibt stehen
# ergänzt durch:
echo "Eingabe         : '", $_POST['f']['password'], "'</br>";
echo "Hash der Eingabe: '", crypt($_POST['f']['password'], $row['password']), "'</br>";
echo "gespeichert     : '", $row['password'], "'</br>";
exit;

Jörg Reinholz

hab es für einen testuser probiert:

Eingabe : 'testpw' Hash der Eingabe: 'teEFewfPtNqgk' gespeichert : 'testpw'

[Auge]

Hallo

Bei der Registrierung landet immer ein kryptisches PW in der DB (Bsp: $2a$10$XtLQOU91xzqedN...)

Zeige uns bitte nach Ergänzen und Ausführen der Login.php:

hab es für einen testuser probiert:

Eingabe : 'testpw' Hash der Eingabe: 'teEFewfPtNqgk'

Das sieht dem oben gezeigten Beispiel garnicht ähnlich. Das sieht nach klassischem™ (völlig veraltetem) Crypt oder MD5 aus.

gespeichert : 'testpw'

Das gespeicherte Passwort ist ungehasht. Damit kann der Vergleich nie stimmen.

Tschö, Auge

[Jörg Reinholz]

Moin!

Bei der Registrierung landet immer ein kryptisches PW in der DB (Bsp: $2a$10$XtLQOU91xzqedN...)

Die Daten, die Du uns jetzt zeigst sind irgendwie mit dieser Aussage nicht in Übereinstimmung zu bringen.

Gehe zurück zu den Original-Skripten von Suit (aus dem Wiki). Die habe ich getestet, die gehen.

Ändere, so Du in einem Unterverzeichnis testen willst,

in der register.php:

header('Location: http://' . $_SERVER['HTTP_HOST'] . '/login.php');

zu

header('Location: ./login.php'); 

in der login.php (zwei mal):

header('Location: http://' . $_SERVER['HTTP_HOST'] . '/index.php');

zu:

header('Location: ./index.php');

in der auth.php:

header('Location: http://' . $_SERVER['HTTP_HOST'] . '/login.php');

zu

header('Location: ./login.php');

In der logout.php steht es schon richtig falsch (Es ist formal falsch, geht derzeit aber....)

Wenn es dann immer noch nicht geht würde es sich lohnen über Deine PHP-Installation sehr intensiv nachzudenken. (etwa Xampp aus einer Zeitschrift von 1999?)

Jörg Reinholz

[Sasser]

Eine Sache ist mir außerdem noch unklar. Wenn ich die Verbindungsdaten zur DB fehlerhaft in der register.php eintrage und versuche, mich zu registrieren, kommt der Fehler 'Der Benutzername ist bereits vergeben.'

Hier der entsprechende Abschnitt:

$mysqli = @new mysqli('xxx', 'xxx', 'xxx', 'xxx');
			if ($mysqli->connect_error) {
				$message['error'] = 'Datenbankverbindung fehlgeschlagen: ' . $mysqli->connect_error;
			}
			$query = sprintf(
				"INSERT INTO users (username, password)
				SELECT * FROM (SELECT '%s', '%s') as new_user
				WHERE NOT EXISTS (
					SELECT username FROM users WHERE username = '%s'
				) LIMIT 1;",
				$mysqli->real_escape_string($_POST['f']['username']),
				$mysqli->real_escape_string($_POST['f']['password']),
				$mysqli->real_escape_string($_POST['f']['username'])
			);
			$mysqli->query($query);
			if ($mysqli->affected_rows == 1) {
				$message['success'] = 'Neuer Benutzer (' . htmlspecialchars($_POST['f']['username']) . ') wurde angelegt, <a href="login.php">weiter zur Anmeldung</a>.';
				header('Location: http://' . $_SERVER['HTTP_HOST'] . '/login.php');
			} else {
				$message['error'] = 'Der Benutzername ist bereits vergeben.';
			}
			$mysqli->close();

Mir ist unklar, warum er trotz einer erfüllten Bedingung in den else-Block springt und die falsche Meldung ausgibt.

[Tabellenkalk]

Hallo,

Mir ist unklar, warum er trotz einer erfüllten Bedingung in den else-Block springt und die falsche Meldung ausgibt.

Für den Datenbankfehler hast du keinen Else-Block. Also tut dein Script so, alsob, und überschreibt die vorhandene Fehlermeldung mit einer Folgefehler-Meldung.

Gruß
Kalk

[Jörg Reinholz]

Moin!

Eine Sache ist mir außerdem noch unklar.

Du hast das Error-Reporting ** error-reporting(E_ALL)** nicht angeschaltet. Sollst du aber in der Phase des Entwickelns und geschlossener Tests.

Ja. Es handelt sich ausdrücklich um Beispiele. Willst Du alle Fehler abfangen, dann benutze meine Geschichte mit PHP und "use strict" bzw. "option explicit"

Wenn PHP Notizen schmeisst, dann ist es wahrscheinlich, dass logische Fehler auftreten. Deshalb ist das Programm frühestens dann fertig, wenn keine Notizen geworfen werden.

Jörg Reinholz

[dedlfix]

Tach!

Eine Sache ist mir außerdem noch unklar.

Du hast das Error-Reporting ** error-reporting(E_ALL)** nicht angeschaltet.[...]

Das ist zwar generell nicht verkehrt, aber hilft in dem Fall nicht, weil da die Programmlogik defekt ist. Wenn die Verbindung zur Datenbank nicht aufgebaut werden kann, ist es nicht sinnvoll, einfach weiterzumachen und Querys auf sie zu feuern. Es fehlt(e) ein else-Zweig.

dedlfix.

[Jörg Reinholz]

Moin!

Das ist zwar generell nicht verkehrt, aber hilft in dem Fall nicht.

Doch. Da müsste wenigstens eine Notiz geschmissen werden, die nach "Beheb das Problem" aussieht.

Jörg Reinholz

[dedlfix]

Tach!

Doch. Da müsste wenigstens eine Notiz geschmissen werden, die nach "Beheb das Problem" aussieht.

Nein, so eine kommt nicht, weil in dem Code nicht auf irgendetwas nicht vorhandenes zugegriffen wird.

Du meinst sicher sowas wie

$result = $mysqli->query(...);
$result->fetch_irgendwas();

Dann steht in $result ein false und das hat keine Methode fetch_irgendwas(). Das gibt aber eine ganz deutliche Fehlermeldung und nicht nur eine Notice.

dedlfix.

[Jörg Reinholz]

Moin!

Dann steht in $result ein false und das hat keine Methode fetch_irgendwas(). Das gibt aber eine ganz deutliche Fehlermeldung und nicht nur eine Notice.

Hm. Stimmt. Habe es getestet (Grund: ging schneller als nachlesen)

# Die hier fehlt, weil suit diese unterdrückt hat:
Warning: mysqli::mysqli(): (28000/1045): Access denied for user 'root'@'localhost' (using password: YES) in /var/www/local/selfhtml2/login.php on line 12

# Diese erfolgen mit error_reporting(E_ALL):

Warning: mysqli::real_escape_string(): Couldn't fetch mysqli in /var/www/local/selfhtml2/login.php on line 18

Warning: mysqli::query(): Couldn't fetch mysqli in /var/www/local/selfhtml2/login.php on line 20

Fatal error: Call to a member function fetch_array() on a non-object in /var/www/local/selfhtml2/login.php on line 21

Der fatale Fehler steht im klaren Widerspruch zur Aussage von Sasser. Das Skript bricht da ab.

Fazit:

Da jetzt keiner mehr weiß, was der Sasser am Skript alles verändert hat:

Sasser: Zurück auf Anfang. Benutze die Skripte von Suit oder zeige uns Deinen Quellcode und vor allem Deine PHP-Version.

<?php echo phpversion(); ?>

liefert die. Ohne dieses gibt es keine Basis für weitere Hilfe.

Jörg Reinholz

[Msass]

Moin!

Dann steht in $result ein false und das hat keine Methode fetch_irgendwas(). Das gibt aber eine ganz deutliche Fehlermeldung und nicht nur eine Notice.

Hm. Stimmt. Habe es getestet (Grund: ging schneller als nachlesen)

# Die hier fehlt, weil suit diese unterdrückt hat:
Warning: mysqli::mysqli(): (28000/1045): Access denied for user 'root'@'localhost' (using password: YES) in /var/www/local/selfhtml2/login.php on line 12

# Diese erfolgen mit error_reporting(E_ALL):

Warning: mysqli::real_escape_string(): Couldn't fetch mysqli in /var/www/local/selfhtml2/login.php on line 18

Warning: mysqli::query(): Couldn't fetch mysqli in /var/www/local/selfhtml2/login.php on line 20

Fatal error: Call to a member function fetch_array() on a non-object in /var/www/local/selfhtml2/login.php on line 21

Der fatale Fehler steht im klaren Widerspruch zur Aussage von Sasser. Das Skript bricht da ab.

Fazit:

Da jetzt keiner mehr weiß, was der Sasser am Skript alles verändert hat:

Sasser: Zurück auf Anfang. Benutze die Skripte von Suit oder zeige uns Deinen Quellcode und vor allem Deine PHP-Version.

<?php echo phpversion(); ?>

liefert die. Ohne dieses gibt es keine Basis für weitere Hilfe.

Jörg Reinholz

Nachdem anfangs die Eintragung in die Datenbank über register.php funktioniert hat, kriege ich mittlerweile nur noch unpassende Fehler. In der Zwischenzeit hatte ich mich aber ausschließlich mit der Anleitung von dir beschäftigt, weshalb der aktuelle Stand in dieser Sache mich verwirrt. Die Pfade habe ich, wie von dir beschrieben, angepasst. Dass sich etwas geändert hat, konnte ich dadurch aber nicht beobachten.

Es war keine gute Idee, die verschiedenen Anleitungen durcheinander verstehen zu wollen. Damit habe ich mir selbst ein Bein gestellt. Eventuell habe ich auch mal eine Datei falsch gespeichert, weshalb jetzt keine DB-Eintragung mehr funktioniert. Das werde ich heute noch genauer untersuchen und anschließend einen Endpunkt setzen, ab dem ich mich ausschließlich mit dieser Anleitung befasse.

Btw. An der PHP-Version kann es nicht liegen. Diese wird von meinem Hoster aktuell gehalten

[Camping_RIDER]

Aloha ;)

Wie kommt dieser Fehler zustande? Hat da jemand eine Idee? Hängt das eventuell mit der Session zusammen?

Ich habe mal den betreffenden Teil des Quellcodes kopiert, damit man daran weiteranalysieren kann:

if (crypt($_POST['f']['password'], $row['password']) == $row['password']) {
	session_start();

	$_SESSION = array(
		'login' => true,
		'user'  => array(
			'username'  => $row['username']
		)
	);
	$message['success'] = 'Anmeldung erfolgreich, <a href="index.php">weiter zum Inhalt.';
	header('Location: http://' . $_SERVER['HTTP_HOST'] . '/index.php');
} else {
	$message['error'] = 'Das Kennwort ist nicht korrekt.';
}

Meiner Meinung nach bedeutet das, dass Folgendes in deiner Situation eben nicht gilt:

crypt($_POST['f']['password'], $row['password']) == $row['password']

Lass dir doch mal die betreffenden Variableninhalte ausgeben. Mir kommt die crypt-Funktion hier auch irgendwie spanisch vor (warum sollte $row['password'] als salt verwendet werden?!?), genauso wie ich den Absatz über die Schlüssel in "Registrieren eines neuen Benutzers" für inhaltlich fragwürdig halte. Es gilt halt eben der disclaimer

Artikel in Benutzernamensräumen sind möglicherweise nicht mehr aktuell oder gar fehlerhaft.

...und da haben wir auch den Salat, im Skript zur Registrierung steht

$_POST['f']['password'] = crypt(
	$_POST['f']['password'],
	'$2a$10$' . $salt
);

Der Salt ist also beim Registrieren ein ganz anderer als beim Login. Der beim Login macht, wie gesagt, auch gar keinen Sinn.

Wenn du den Salt im Login-Vorgang durch den korrekten salt ersetzt, sollte alles funktionieren (sofern nicht weitere Fehler im Quellcode sind).

Ich kann dir nur empfehlen, dich stattdessen an den Artikel Loginsystem von @Jörg Reinholz zu halten; der ist deutlich aktueller und im Hauptnamensraum, d.h. er unterliegt (im Gegensatz zu Artikel-Skizzen im Benutzernamensraum) auch der Wartung durch die Community.

Grüße,

RIDER

[Christian Kruse]

Hallo Camping_RIDER,

Meiner Meinung nach bedeutet das, dass Folgendes in deiner Situation eben nicht gilt:

crypt($_POST['f']['password'], $row['password']) == $row['password']

Lass dir doch mal die betreffenden Variableninhalte ausgeben. Mir kommt die crypt-Funktion hier auch irgendwie spanisch vor (warum sollte $row['password'] als salt verwendet werden?!?),

Weil das Salt als Prefix an das Ergebnis der Crypt-Funktion vorangestellt wird. Aus crypt("ab", "cd") wird also "cd<cryptwert>". Siehe auch das Manual.

...und da haben wir auch den Salat, im Skript zur Registrierung steht

$_POST['f']['password'] = crypt(
	$_POST['f']['password'],
	'$2a$10$' . $salt
);

Der Salt ist also beim Registrieren ein ganz anderer als beim Login.

Nein.

Ich kann dir nur empfehlen, dich stattdessen an den Artikel Loginsystem von @Jörg Reinholz zu halten; der ist deutlich aktueller und im Hauptnamensraum, d.h. er unterliegt (im Gegensatz zu Artikel-Skizzen im Benutzernamensraum) auch der Wartung durch die Community.

Ja.

LG,
CK

[Auge]

Hallo

Das verstehe ich nicht.

crypt($_POST['f']['password'], $row['password']) == $row['password']

Lass dir doch mal die betreffenden Variableninhalte ausgeben. Mir kommt die crypt-Funktion hier auch irgendwie spanisch vor (warum sollte $row['password'] als salt verwendet werden?!?),

Weil das Salt als Prefix an das Ergebnis der Crypt-Funktion vorangestellt wird. Aus crypt("ab", "cd") wird also "cd<cryptwert>". Siehe auch das Manual.

Ok, der Code im ersten der verlinkten Beispiele gleicht dem des fraglichen Artikels. Beim anlegen des Benutzers sieht er logischerweise anders aus ($_POST['f']['password'] = crypt($_POST['f']['password'], '$2a$10$' . $salt)), da in diesem Moment noch kein Passwort zum Vergleich mit der Eingabe existiert. Wie sucht sich die Funktion bei einem Aufruf zum Vergleich aus einem bestehenden Passwort den Salt? Das gesamte Passwort wird sie als Salt ja nicht nehmen können, denn er ist es ja nicht. Auf der Dokuseite habe ich dazu nichts gefunden.

Tschö, Auge

[Christian Kruse]

Hallo Auge,

Wie sucht sich die Funktion bei einem Aufruf zum Vergleich aus einem bestehenden Passwort den Salt? Das gesamte Passwort wird sie als Salt ja nicht nehmen können, denn er ist es ja nicht. Auf der Dokuseite habe ich dazu nichts gefunden.

crypt() verwendet als Salt eine feste Anzahl von Zeichen, abhängig vom Algorithmus. Bei dem alten DES-Algorithmus wurden fest 2 Zeichen verwendet, bei dem neueren MD5 werden 12 Zeichen verwendet. Steht auch in der Doku, bei der Beschreibung der verschiedenen crypt()-Algorithmen. Die Funktion benutzt dann immer nur so viele Zeichen, wie der verwendete Algorithmus definiert. Welcher Algorithmus das ist, ist wiederum am Salt erkennbar, anhand des Prefixes: siehe Doku ;-)

LG,
CK

[Auge]

Hallo

crypt() verwendet als Salt eine feste Anzahl von Zeichen, abhängig vom Algorithmus. … Welcher Algorithmus das ist, ist … am Salt erkennbar …

Das war der Knackpunkt. Danke.

Tschö, Auge

[Jörg Reinholz]

Moin!

Wie sucht sich die Funktion bei einem Aufruf zum Vergleich aus einem bestehenden Passwort den Salt?

So:

<?php
$hash='$2a$10$Ktv2Ar1JEm2W7gie/7DNwut1vfLNDj6G7uzux6P..EK';
$ar=explode('$', $hash);
echo "Methode: ", $ar[1], "<br>\n";
echo "Runden : ", pow(2, $ar[2]), "<br>\n";
if ($ar[1] == "2a" or $ar[1] == "2y") {
   echo "Salt : ", substr ( $ar[3] , 0, 21 ), "<br>\n";
}

Für andere Methoden musst Du halt die Länge des Salt selbst heraussuchen.

Jörg Reinholz

[Sasser]

[TUFO/TOFU entfernt]

Danke! Ich werde deine Tipps befolgen und michdann nochmal zu Wort melden. Ich hab auch schon einen Blick auf deinen Link geworfen - sehr interessant. Vielen Dank.

und Zack, Forum in den Favoriten :)

[Camping_RIDER]

Aloha ;)

Danke! Ich werde deine Tipps befolgen und michdann nochmal zu Wort melden. Ich hab auch schon einen Blick auf deinen Link geworfen - sehr interessant. Vielen Dank.

Beachte bitte auch den Hinweis von Christian; wie du merkst ist Detailkenntnis zu Verschlüsselung auch nicht mein täglich Brot (bisher) ;) Es kann aber trotz der Einwände von Christian sein, dass an dieser Stelle irgendwas interferiert, was mit dem salt in crypt zu tun hat, das wir beide noch nicht auf dem Schirm hatten.

und Zack, Forum in den Favoriten :)

Weiter so ;)

Grüße,

RIDER

[Auge]

Hallo

Meiner Meinung nach bedeutet das, dass Folgendes in deiner Situation eben nicht gilt:

crypt($_POST['f']['password'], $row['password']) == $row['password']

Lass dir doch mal die betreffenden Variableninhalte ausgeben. Mir kommt die crypt-Funktion hier auch irgendwie spanisch vor (warum sollte $row['password'] als salt verwendet werden?!?),

Der ist mir auch aufgefallen und der wird's mit an Sicherheit grenzender Wahrscheinlichkeit auch sein. Der Salt wird, soweit ich weiß, zuzüglich weiterer Infos z.B. über seine Länge, dem gehashten Passwort beim speichern vorangestellt. Beim Login muss dieser Abschnitt aus dem Passwort gepopelt und statt dessen an die Funktion crypt übergeben werden.

Ich kann dir nur empfehlen, dich stattdessen an den Artikel Loginsystem von @Jörg Reinholz zu halten; der ist deutlich aktueller und im Hauptnamensraum, d.h. er unterliegt (im Gegensatz zu Artikel-Skizzen im Benutzernamensraum) auch der Wartung durch die Community.

Schon alleine dieser Umstand reicht. :-)

Tschö, Auge

[Jörg Reinholz]

Moin!

r> Lass dir doch mal die betreffenden Variableninhalte ausgeben. Mir kommt die crypt-Funktion hier auch irgendwie spanisch vor (warum sollte $row['password'] als salt verwendet werden?!?), genauso wie ich den Absatz über die Schlüssel in "Registrieren eines neuen Benutzers" für inhaltlich fragwürdig halte. Es gilt halt eben der disclaimer

So ganz unlogisch ist das nicht.

crypt ist nicht in allen Aspekten die Superlösung. So ist z.B. die Tatsache, dass man sich bei der Registrierung den Salt selber bauen muss nicht mehr ganz modern.

Jetzt zum Login. crypt nimmt das gehashte Passwort und extrahiert daraus den Salt. Der steht nämlich drin (und das ist richtig so, muss so sein) Das sollte funktionieren.

# tatsächlich benutzt wird:
# eingegebenes Passwort      , Salt aus dem      == gespeicherten Passwort
crypt($_POST['f']['password'], $row['password']) == $row['password']

Sieht halt nur ulkig aus...

Jörg Reinholz

[Jörg Reinholz]

Definitiv! Ich habe das gerade eben getestet...

Deshalb brauchen wir Deinen konkreten Code. Oder Du musst selbst debuggen…

Jörg Reinholz

[Felix Riesterer]

Lieber Sasser,

das Verschlüsseln und Testen auf Gültigkeit macht man in PHP offensichtlich mittlerweile über die beiden Funktionen password_hash() und password_verify(). Anscheinend ist die Nutzung von crypt gerade für Neulinge auf dem Gebiet zu missverständlich gewesen - neben so anderen wichtigen Dingen wie Salt und verwendetem Algorithmus/Cipher-Suite und dergleichen mehr, welche von diesen beiden Funktionen intern automatisch optimiert werden.

Noch dazu ist bei den beiden Funktionen eine Kompatibilität mit per crypt erzeugten Passwort-Hashes gegeben!

Liebe Grüße,

Felix Riesterer.

[Jörg Reinholz]

Moin!

Noch dazu ist bei den beiden Funktionen eine Kompatibilität mit per crypt erzeugten Passwort-Hashes gegeben!

Stimmt.

Von mir propagierte Übergangsfunktionen:

if (! function_exists('password_hash') ) {
     function create_salt ($l=22, $allowed='1234567890abcdefghijklmnopqrstuvwxyzABCDEFGHIJLKMNOPQRSTUVWXYZ./') {
        $salt='';
        for ( $i = 0; $i < $l; $i++ ) {
            $salt .= $allowed{rand( 0, strlen($allowed) - 1 )};
        }
        return $salt;
     }
 
     function password_hash ($password, $dummy) {
         return crypt( $password, '$2y$10$' . create_salt() .'$' );
     }
 
     function password_verify ($password, $hash) {
         return ( $hash == crypt($password, $hash) );
     }
 
     function password_needs_rehash ($hash, $dummy) {
        return ('$2y$10$' != substr($hash, 0, 7) );
     }
}

Jörg Reinholz

[Jörg Reinholz]

Moin!

Diese Frage bezieht sich auf das Loginsystem von Jörg Reinholz

Auf der Testseite kann ich mich mit keinem der angegebenen Nutzer einloggen. Es kommt bei jedem Versuch die Meldung, dass das Passwort nicht korrekt ist.

Liegt hier tatsächlich ein Fehler vor, oder ist der Login noch in Bearbeitung?

Nein. Ganz einfache Sache: Das Login-System funktioniert, aber irgendwer hat die Passwörter geändert (was ja auch geht und getestet werden können soll).

Ich habe also die Passwörter zurück gesetzt und jetzt kann man sich wieder mit "GeHeim" anmelden. Nur nicht als root: Den Zugang brauche ich, um die Passwörter bequem zurück setzen zu können ...

Jörg Reinholz