Welcome to the CMSimple_XH–Community!
https://cmsimpleforum.com/
Ja, das liegt höchst wahrscheinlich an der PHP-Version. Für PHP < 5.5.0 liefern wir ein Kompatibilitätsscript für das gilt:wbs wrote:Ich habe CMSimple_XH auf einem Server mit PHP 5.3.3-7+jessie1 installiert. Ich kann mich allerdings nichteinmal mit dem Standardpasswort einloggen, es kommt immer "Sie haben ein falsches Passwort eingegeben!". Kann das an der PHP-Version liegen? Das Passwort ist sicher das Standardpasswort, ich habe den Hash in der config.php abgeglichen.
Daher wird auch in der Systemprüfung PHP ≥ 5.3.7 geprüft. Wenn irgend möglich solltest du sowieso eine aktuellere PHP-Version verwenden.This library requires PHP >= 5.3.7 OR a version that has the $2y fix backported into it (such as RedHat provides). Note that Debian's 5.3.3 version is NOT supported.
Passwörter im Klartext zu speichern, ist eine Sicherheitslücke – wäre also ein sehr schlechter Workaround. Zu PHP 5.3.3-7+jessie1 kann ich im Web keine Informationen finden; ich kann mir aber eigentlich schwer vorstellen, dass dieses Paket noch mit Sicherheitsfixes versorgt wird (PHP 5.3.3. wurde vor über 7 Jahren veröffentlicht). Ein Beleg dafür scheint das Fehlverhalten von password_verify(), welches wenig mehr als ein Wrapper über crypt() ist, und offensichtlich wurde der $2y Patch nicht portiert. Da sollte also eigentlich der Serveradmin tätig werden, und auf eine geflegte PHP-Version aktualisieren.wbs wrote:Ah okay, gibts da kein Workaround, z.B. dass man das Passwort in Klartext speichern lässt? Ich weiß nicht, ob ein PHP-Update eine Option ist.
Spricht sonst was sicherheitstechnisch dagegen, 5.3.3 zu verwenden?
Code: Select all
$cf['security']['password']="$2a$10$3ea934f04d67273807ea9uqGmbd35SRQq6p6lfkjfTkBZD9NnOwZK"; Code: Select all
$hash_format = sprintf("$2a$%02d$", $cost); 
Nicht wirklich. Das $2y$ wurde durch $2a$ ersetzt.wbs wrote:Das ist doch die unveränderte Zeile?
Das scheint mir andere Gründe zu haben, denn ich vermute, dass die eigentliche Passwortprüfung erfolgreich war, aber es ein Problem mit den Cookies oder der Session selbst gibt. Zur Prüfung: lösche die Cookies der Domain, logge dich ein, und prüfe, ob mode, status und das Session-Cookie (XH_irgendwas) gesetzt wurde. Falls ja, dann aktiviere den Debug-Modus, und logge dich erneut ein – dann könnte eine auf die Session bezogene Warnmeldung erscheinen.wbs wrote:Jetzt kann ich mir zwar einloggen, werd aber nach jedem Klick auf der Seite ausgeloggt.
Dann solltest du vielleicht einmal die Response-Header direkt nach dem Login prüfen (z.B. in der Browserkonsole); dort sollten entsprechende Set-Cookie Header vorhanden sein. Falls nicht, dann kann ich mir eigentlich nur vorstellen, dass die Site bereits Ausgabe erzeugt hat, so dass die Header nicht mehr gesendet werden konnten – das sollte aber der Debug-Modus eigentlich melden ("Cannot send headers – output already started in …").wbs wrote:Es sind keine Cookies von der Domain hinterlegt.
Ich hab jetzt nochmal eine neue, unveränderte (bis auf die Passwortsache) Installation getestet, gleiches Ergebnis, Debug sagt nichts.
Code: Select all
define('XH_ADM', true);