Probleme beim Update / Neuinstallation und Datenbankwiederherstellung

[mr.august]

Ich kann meinen letzten Beitrag irgendwie nicht bearbeiten, daher hier kurzer Nachtrag :

Habe es jetzt per Einzelimport verschiedener Tabellen geschafft, Kunden und Produkte etc. in den neuen Shop zu integrieren.
Allerdings gibt es, vermutlich durch den PHP 7 und 8 Unterschied, Probleme bei den Kundendaten. Ich kann mich nicht mehr einloggen, auch ein Passwort Reset bringt nichts. Scheint einfach nicht in der Tabelle gespeichert zu werden bzw. nicht abrufbar zu sein. Er erkennt zwar mein Konto, aber zeigt immer wieder dass das Passwort falsch sei.

[profrolfwolf]

Hallo August

Ich kann dir nciht sagen, warum das einspielen der DB Sicherung nicht klappt, bzw. ob das überhaupt das Problem ist?

Wobei ich habe eine neue DB angelegt, und bin mit dieser durch die Systeminstallation, und habe erst als alles lief die Sicherung "wiederhergestellt"

Bei mir war es allerdings so, das ich nach dem einspielen der DB sicherung noch einmal den /_installer ordner hochgeladen habe, und nochmals das DB update, und auch das DB Struktur Update gemacht habe. Klar, DB war ja noch aus der Version 2.0.5.1

Danach noch den Unterstrich aus der .Htacess entfernt, und dann lief es bei mir problemlos.

Nachtrag, php Version muß natürlich für die neue Version auch stimmen

Hoffe es hilft dir

[mr.august]

Hallo  profrolfwolf, danke für deine Antwort.

Leider liegt hier ja genau das Problem. Ich kann den Shop in der aktuellen Version installieren und problemlos zum laufen bekommen, die Probleme beginnen ab Datenbank Wiederherstellung.

Auch die DB Updates über den Installer funktionieren nicht, wie 2 Beiträge vorher geschrieben.
Dort erhalte ich immer ein Fenster ohne Inhalt.

Indem ich die Tabellen einzeln importiere, kann ich zumindest Produkte und Kategorien wiederherstellen.
Aber bei Kundendaten hört es dann schon wieder auf. Die Tabelle kann ich zwar auch importieren, werden auch im Backend angezeigt, aber man kann sich einfach nicht mehr einloggen. Er meckert dann über falsche Passwörter, auch über frisch zurück gesetzte.

[Timm]

Was steht denn im log, wenn die DB Updates nicht gemacht werden. Gibt dann ein mod_installer.log oder so ähnlich vom Namen.

Gruß Timm

[mr.august]

Hallo Timm,

danke für deine Antwort.

Wenn ich die Tabellen einzeln importiere, taucht seltsamerweise gar kein Fehler in der mod_installer.log auf.
Obwohl man sich nicht einloggen kann und er immer wieder über ein falsches Passwort schimpft ( was vorher frisch zurückgesetzt wurde... )

Wenn ich die komplette Datenbank aus dem alten Shop importiere, wird eine mod_error.log erstellt.

Darin taucht dann auf :

Code: PHP  [Auswählen]

[2024-02-26 21:04:49]   [error] [modified]      [pid:450624]    ERROR found for URL: /login.php {}      {}
[2024-02-26 21:04:49]   [error] [modified]      [pid:450624]    array_values(): Argument #1 ($array) must be of type array, null given in File: /home/users/.../www/httpdocs/.../inc/xtc_get_countries.inc.php on Line: 37      {}      {}
[2024-02-26 21:04:52]   [error] [modified]      [pid:450624]    ERROR found for URL: /  {}      {}
[2024-02-26 21:04:52]   [error] [modified]      [pid:450624]    Unknown column 'banners_sort' in 'order clause' in File: /home/users/.../www/httpdocs/.../inc/db_functions_mysqli.inc.php on Line: 192  {}      {}
[2024-02-26 21:04:53]   [error] [modified]      [pid:450624]    ERROR found for URL: /  {}      {}
[2024-02-26 21:04:53]   [error] [modified]      [pid:450624]    Unknown column 'banners_sort' in 'order clause' in File: /home/users/.../www/httpdocs/.../inc/db_functions_mysqli.inc.php on Line: 192  {}      {}
 

( "..." ersetzt in dem Fall die Order meines Servers )

[Timm]

Moin

Ich meinte wenn du den _installer laufen lässt und das DB Update nicht durchgeführt wird, nachdem du die komplette alte DB importiert hast und sie updaten möchtest mit DB Update und DB Strukturupdate. Ein mod_installer.log wird nur beim ausführen des _installer erstellt. Und da liegt doch dein Problem, dass das nicht durchläuft.

Ich rate dir davon ab Tabellen einzeln zu importieren. Ich vermute du weißt nicht genau welche von einander abhängig sind und welche alle übertragen werden müssen.

Das man sich nicht einloggen kann mit einer alten DB kann daran liegen, dass in neueren Shopversionen die Verschlüsselungsmethode geändert wurde. Erst durch den _installer werden die gespeicherten Passwörter der alten DB dann umgeschrieben auf die neue Verschlüsselungsmethode.

Die error sind normal, weil du einen aktuellen Shop hast, aber es in der alten DB Spalten wie banner_sort nicht gab. Somit findet er das in der alten DB nicht. Wenn der _installer durchlaufen würde, dann wären diese Spalten angelegt und du könntest Banner sortieren.

Gruß Timm

[p3e]

... Erst durch den _installer werden die gespeicherten Passwörter der alten DB dann umgeschrieben auf die neue Verschlüsselungsmethode....

Das würde mich wundern. Die Passwörter werden als Hashwert in der Datenbank gespeichert. Ein Hashwert zeichnet sich dadurch aus, dass er nur in eine Richtung errechnet werden kann (das hat den Sinn, dass man auch mit Zugang zur Datenbank nicht das Passwort auslesen kann). Meines Wissens kann man nicht einfach den Hashwert einer Methode in den Hashwert einer sichereren Methode umrechnen.
Es könnte höchstens sein, dass modified ab einer bestimmten Version zum verifizieren die alte Hashwertberechnung und im Anschluss den erhaltenen Hashwert wiederum mit einem neuen und sichereren Verfahren erneut in einem Hashwert umwandelt. Sollte modified diese Weg gegangen sein, dann wäre ein Update der Methode in Form der zwei Schritte tatsächlich möglich (und wenn ich so recht überlege auch ziemlich genial ).

[mr.august]

Hallo Timm,

ah sorry falsch verstanden.

In der mod_installer log steht nach dem DB Update (welches nicht klappt ) :

Code: PHP  [Auswählen]

[2024-02-27 14:02:59]   [error] [modified]      [pid:583597]    ERROR found for URL: /_installer/update.php?action=sql_update_process   {}      {}
[2024-02-27 14:02:59]   [error] [modified]      [pid:583597]    Call to undefined function error_log() in File: /home/users/.../www/httpdocs/.../_installer/includes/functions.php on Line: 605 {}      {}

[Timm]

... Erst durch den _installer werden die gespeicherten Passwörter der alten DB dann umgeschrieben auf die neue Verschlüsselungsmethode....

Das würde mich wundern. Die Passwörter werden als Hashwert in der Datenbank gespeichert. Ein Hashwert zeichnet sich dadurch aus, dass er nur in eine Richtung errechnet werden kann (das hat den Sinn, dass man auch mit Zugang zur Datenbank nicht das Passwort auslesen kann). Meines Wissens kann man nicht einfach den Hashwert einer Methode in den Hashwert einer sichereren Methode umrechnen.
Es könnte höchstens sein, dass modified ab einer bestimmten Version zum verifizieren die alte Hashwertberechnung und im Anschluss den erhaltenen Hashwert wiederum mit einem neuen und sichereren Verfahren erneut in einem Hashwert umwandelt. Sollte modified diese Weg gegangen sein, dann wäre ein Update der Methode in Form der zwei Schritte tatsächlich möglich (und wenn ich so recht überlege auch ziemlich genial ).

War viellicht laienhaft geschrieben, weil ich davon keine Ahnung habe. Hatte deshalb auch extra "kann daran liegen" geschrieben. Hatte nur im Hinterkopf, dass ich da mal was im Bugtracker gesehen hatte.

Die beiden Changesets hab ich auf die schnelle gefunden und sind für Shopversion 3.0.0, also neuer als seine alte DB.

changeset 14636 - add option to use password pepper on password hashes

changeset 14639 - revised r14636 (use new password hash)

Grüße Timm

[Q]

Ich würde sagen, Timm hat zu Teilen recht. Soweit ich weiß, wurde früher "nur" mit md5 gehashed und inzwischen mit Salt/Pepper verbessert. Bei neuen Accounts wird direkt der Hash nach neuer Hashmethode in der DB gespeichert. Bei "alten" Accounts wird der Passworthash erst nach neuer Methode, bei Missmatch nach alter Methode geprüft und bei Erfolg der Hash des Pw nach neuer Methode in die DB geschrieben (="Update alten Hash mit neuen Hash"). Denn wie p3e richtig schreibt, sind Hashes nicht rückrechenbar. MD5 ist inzwischen aber zu unsicher geworden. Stichwort Rainbow Tables.
Die Änderung (Salt) kam glaub mit der 2er (oder 1.06?) Version mit Verbesserung (Pepper) zur 3er.

[Q]

Habe es jetzt per Einzelimport verschiedener Tabellen geschafft, Kunden und Produkte etc. in den neuen Shop zu integrieren.
Allerdings gibt es, vermutlich durch den PHP 7 und 8 Unterschied, Probleme bei den Kundendaten. Ich kann mich nicht mehr einloggen, auch ein Passwort Reset bringt nichts. Scheint einfach nicht in der Tabelle gespeichert zu werden bzw. nicht abrufbar zu sein. Er erkennt zwar mein Konto, aber zeigt immer wieder dass das Passwort falsch sei.

Hier ist das Problem vermutlich die Reihenfolge. Soweit ich das Beurteilen kann, hat das alten Datenbankfeld für die Passwörter eine Länge von max. 60 Zeichen. In der neuen DB von max. 255 Zeichen. Wenn Du jetzt mit den neuen Shopdateien in einer alten DB Struktur dich einloggst oder das Passwort zurücksetzt, wird nach neuer Methode (siehe mein Post vorher) vermutlich gehashed. Der Hash ist über 60 Zeichen lang und abgeschnitten in die DB geschrieben. Damit matched bei erneuter Anmeldung der Hash vom eingegeben Pw nicht mit dem "kaputten" Hash in der DB.

Versuche mal direkt in der DB die Feldgröße für das Passwort in der Tabelle customers auf 255 zu erhöhen und setzt dann das Passwort nochmal zurück und versuche dann die DB Updates über den Installer zu fahren.

[mr.august]

Danke für den Input, wollte ich direkt mal umsetzen aber ich glaube der Wert ist auch schon in der "alten" Datenbank auf 255 oder?

[Timm]

Moin

In meiner DB ist der Wert in 2.0.7.2 noch 60. Da muss was falsch sein bei dir. Anscheinend wurde die DB schon versucht upzudaten.

Gruß Timm

[mr.august]

Das ist ja sehr eigenartig. Hab noch keinen Update Versuch mit dem aktuellen Shop gestartet, daher wundert mich das sehr.

Wenn die Kunden nach dem Shop Wechsel nur ein neues Passwort beantragen müssten, könnte ich damit auch gut leben. Aber ich kann nicht alle Konten auf dem alten Shop zurücklassen.

[mr.august]

Kurze Zwischenfrage die mir gerade so ein- / auffällt :

Wenn ich jetzt doch den "klassischen" Weg des Updates gehe und die einzelnen Updates bis 2.0.7.2 mache von der ich dann auf >3 gehe , bekomme ich dann nicht spätestens beim letzten Update schritt von 2 auf 3 ein Problem mit der PHP Version ?

Mein Shop in 2.0.5.1 läuft aktuell wie geschrieben auf PHP 7.4 , die Version 3> verlangt ja PHP 8.
Also müsste ich ja dann entsprechend umstellen. Macht das die Datenbank einfach so mit ? Oder scheitert es nicht spätstens dann mit den Updates ?