Kein Login ins Backend

[rethus]

Ich habe ein System inkl. DB kopiert.
Frontend geht, Backend wird angezeigt, kann mich aber nicht einloggen.

Es ist die 4.9.4er Version, die ja mitlerweile auch ein gesalzenes Passwort hat
Muss ich bei einer neuen Plattform das Passwort neu setzen? Eigentlich doch nicht, oder?

Ich erhalte keinerlei Fehlermedungen... weder in der errorlog.txt, noch in der error.log vom apache.
Habe sogar nochmal das Setup (upgrade) drüber laufen lassen, ohne Erfolg.

Hat jemand einen Tipp, woran das liegen kann?

[rethus]

Also das Login-Screen sendet via ajaxmain.php eine Anfrage und erhält von diesem folgendes zurück:

Code: Alles auswählen

{"state":"error","code":401,"message":"Unauthorized"}

[Faar]

Es könnte am Cookie liegen.
Wichtig ist, dass die Session-Cookie Tabelle und andere Caches gelöscht werden, vor oder nach dem Umzug.
Das Problem hatte ich auch einmal und es bestand in der Session, die in der Tabelle gespeichert wird.

[rethus]

Danke für den Tipp, beim Sourcecode hab ich mich auch schon soweit durchgehangelt, dass es an einer Session liegen könnte.

Er landet nämlich in der class.ajax.php in diesem "case"-Statement:

Code: Alles auswählen

  case 'authentication_fail':
                // Not authenticated AJAX request, e. g. invalid or expired session
                $result = array(
                    'state' => 'error',
                    'code' => 401,
                    'message' => 'Unauthorized',
                );
                $string = json_encode($result);
                break;

Kannst du mir sagen welche Tabellen dafür zuständig sind? In der 4.9.4 hat sich ja doch einiges an Tabellen geändert.

[rethus]

Also ich habe nun einmal in class.auth.handler.backend.php ein paar Kontrollausgaben gemacht.

Code: Alles auswählen

     while (($item = $userColl->next()) !== false) {
         //   	var_dump($item);
            $uid = $item->get('user_id');
            $perm = $item->get('perms');
            $pass = $item->get('password'); // Password is stored as a sha256 hash
            $salt = $item->get("salt");
        }
echo hash("sha256", md5($password) . $salt) ." != $pass";
        if ($uid == false || hash("sha256", md5($password) . $salt) != $pass) {
            // No user found, sleep and exit
            sleep(5);

            return false;
        }

Interessanterweise ergab dies, dass das Passwort und der hash nicht übereinstimmen, obwohl ich wie gesagt mit exakt dieser Konstellation in das andere System immernoch rein komme.

Code: Alles auswählen

fc102711d7acfa4339e87c646c2a61166b500f470b90dae5c5b06ea31311513c != 30dcfb7760bd9191193077980e7f2414e10effcdb650ca3ef7809d222e28796d

Das interessante ist jedoch, dass in der Datenbank auch

fc102711d7acfa4339e87c646c2a61166b500f470b90dae5c5b06ea31311513c

im Passwortfeld steht. Ich frage mich also wo er für $pass diesen Wert

30dcfb7760bd9191193077980e7f2414e10effcdb650ca3ef7809d222e28796

herbekommt.

Warum hat er bei $pass = $item->get('password'); plötzlich diesen 30dc... Wert, anstatt der, der wirklich in der DB steht, wohingegen die user_id, perms und salt wiederrum stimmen?
Hat jemand ne Idee, wie das sein kann?

[homtata]

Da ich für einen anderen User hier neulich bei einer Problemlösung für den Backendlogin geholfen habe, würde ich behaupten:
Solange in beiden Installationen in der Tabelle con_user die Einträge für das md5-Passwort und den Salt identisch sind zu den Originaleinträgen, müsstest du mit dem gleichen Passwort ins System kommen.
Wenn also irgendwelche Werte nicht stimmen, würde ich auch eher auf Cache-Werte für Sessions u.ä. tippen.

[MyWorker]

Ich weiß nicht, ob ihr das Problem schon lösen konntet. Ich hatte gerade das selbe Problem. Ich kam in meinem lokalem Contenido nicht mehr ins backend. Dann hab ich mir gültige Werte aus einem anderen kopiert und... ging auch nicht. Die Lösung war: Ich hatte das Datenbankpasswort geändert. Nachdem ich das in der config.php wieder berichtigt hatte, siehe da, konnte ich micht wieder ins Backend einloggen.
Vielleicht hilft deser Tipp ja jemanden.

[Oldperl]

Hallo MyWorker,

Änderungen des Datenbank-Passwortes sollten sich eigentlich im Error-Log in einem "Can' t connect to database" wiederspiegeln. Daher sollte man bei Fehlern grundsätzlich das Error-Log einsehen. Das geht auch ohne Zugriff auf das Backend indem man die Datei direkt per FTP im Verzeichnis data/logs anschaut.

Gruß aus Franken

Ortwin

[rethus]

Ich habe mich nun auch mit dem Problem rumgeschlagen und es gelöst.

Ich hatte in der config (bei mir 4.9.7) folgenden Eintrag

Code: Alles auswählen

$cfg['path']['contenido_fullhtml']      = 'http://my-domain.de/contenido/';

Aufgerufen habe ich das Contenido-Backend aber über 'http://www.my-domain.de/contenido/' (also www. als Subdomain davor).
Damit ist Ajax (im Chrome) ausgestiegen, und hat den oben besagten Fehler verursacht.

[McHubi]

Das Problem hatte ich bei einem Upgrade von einer 4.9.4 auf eine 4.9.6er. Hatte alle Einstellungen beim Setup/Upgrade übernommen - und aus dem bisherigen http://www.meinedomain.de/contenido wurde dann http://meinedomain.de/contenido
Die gleiche manuelle Korrektur in der config-Datei hat dann auch bei mir das Problem behoben. Wäre interessant zu wissen, ob dieser - vermutlich - Fehler bei einem Upgrade auf die aktuelle 4.9.8er auch noch vorkommt und man die beim Upgrade-Vorgang angezeigten bisherigen und zu übernehmenden Einstellungen korrigieren muss weil sie evtl. fehlerhaft sind.