MySQL-5 Kompatibilität

MyOOS hat einen Fehler, oder tut nicht das, was Ihr erwartet? Derartige "Unanehmlichkeiten" bitte hier.
Antworten
moonshot
Beiträge: 24
Registriert: 25.04.2009, 16:35

MySQL-5 Kompatibilität

Beitrag von moonshot »

Hallo,

der Server meines Kunden wurde kürzlich von MysqL4 auf MySQL 5 upgedated. Seitedem ist kein Login in den Admin mehr möglich und eventuell auch mehr. Vermutlich liegt es daran, dass die Version 1.7.14 nicht mit MySQL 5 kompatibel ist. Ist die Version 1.7.15 oder 1.7.16 kompatibel, sodass ein Update das Problem beheben würde?

Grüße,
Peter
r23
Beiträge: 2625
Registriert: 18.09.2008, 05:56
Wohnort: Hagen
Kontaktdaten:

Beitrag von r23 »

Hallo,

das Update auf MySQL 5 hatte nur zur Folge, dass MySQL nun sich etwas mehr an den Standard von SQL halten möchte.

D.h. einfache Anfrage, wie der Login - sind nicht betroffen.. sondern nur alle Abfragen über drei Tabellen mit z.B. LEFT JOIN.

Das MyOOS Projekt schreibt aber seine Probleme in dei oos_temp/logs/*.*

wenn es mit der Datenbank Probleme gibt, was steht in der Error Log Datei vom ADODB?
und wenn es Probleme mit PHP gibt, was steht in der php log Datei.

Heute / pp Morgen veröffentliche wir eine neue 1.7.x Version

Beste Grüße

ralf
moonshot
Beiträge: 24
Registriert: 25.04.2009, 16:35

Beitrag von moonshot »

Hallo Ralf,

Danke für die schnelle Antwort. Also, die Error Log-Dateien werden nicht mit neuen Einträgen gefüttert. Der letzte ADODB-Eintrag ist von 2009 und die php_error_log ist leer. Muss das Logging ggf. aktiviert werden? Wenn ja, wo kann ich das vornehmen? In der Config-Datei konnte ich nur folgenden relevant erscheinenden Eintrag finden: define('ADODB_ERROR_LOG_TYPE', 3); Die dort gesetzten Pfade zur ADODB Error Log-Datei stimmen.

Wo werde ich mir die neue Shop-Version downloaden können? Ansonsten maile sie mir bitte gerne zu.

Schöne Grüße,
Peter
r23
Beiträge: 2625
Registriert: 18.09.2008, 05:56
Wohnort: Hagen
Kontaktdaten:

Beitrag von r23 »

Hallo,

die ADODB Error Log Datei ist bereits aktiv.

Die PHP Error Log Datei muss man einschalten.

Z.b. in der wenn PHP als Modul im Apache läuft
.htaccess
<IfModule mod_php5.c>
php_value error_repoting 2039
php_value display_errors 0
php_value log_errors 1
php_value error_log {logFile}
</IfModule>
anstelle {logFile} den Pfad zur Log Datei /usr/home/www/exampel_org/oos_temp/logs/php_error.log
oder im Script


[quote='moonshot',index.php?page=Thread&postID=1957#post1957]
Wo werde ich mir die neue Shop-Version downloaden können? Ansonsten maile sie mir bitte gerne zu.
[/quote]

Die Version für PHP 5.3.x kann man über den Shop kaufen. Das neue Paket ist allerdings noch nicht fertig.

cu

ralf
moonshot
Beiträge: 24
Registriert: 25.04.2009, 16:35

Beitrag von moonshot »

Hallo Ralf,

Danke, ich habe die .htaccess antsprechend angepasst, bekomme aber keine PHP-Fehlermeldungen. Der Fehler äußert sich wie folgt: Beim Einlog-Versuch in den Adminbereich wird nur die Einlogseite erneut gezeigt und das Passwortfeld entleert.

Gruß,
Peter
r23
Beiträge: 2625
Registriert: 18.09.2008, 05:56
Wohnort: Hagen
Kontaktdaten:

Beitrag von r23 »

Hallo,

welche PHP Version wird verwendet?
wie ist PHP installiert?

Die Änderungen an der .htacess funktionen selbstverständlich nur, wenn PHP als Apache Modul laufen.
Die Dateien in dem Verzeichnis
~/oos_temp/logs/ müssen auch beschreibbar sein.

Wenn diese Informationen vorhaden sind, ist ein "Debuggen" in
~/shop/admin/login.php

sinnvoll. Die Frage, die ich beim debuggen an das Script hätte, wäre vermutlich,

a- was kommt bei der SQL-Abfrage raus

Code: Alles auswählen

      $check_admin_result = $dbconn->Execute("SELECT admin_id as login_id, admin_groups_id as login_groups_id, admin_firstname as login_firstname, admin_email_address as login_email_address, admin_password as login_password, admin_modified as login_modified, admin_logdate as login_logdate, admin_lognum as login_lognum FROM " . $oostable['admin] . " WHERE admin_email_address = '" . oos_db_input($email_address) . "'");
      if (!$check_admin_result->RecordCount()) {
        $_GET['login] = 'fail';
      } else {
        $check_admin = $check_admin_result->fields;
b- wenn nichts an kommt - warum nicht

überprüfen mit

Code: Alles auswählen

print_r($check_admin_result);

Ich hoffe, die Session wird nicht in die DB gespeichert?
und die CAPTCHA Grafik ist aus?
moonshot
Beiträge: 24
Registriert: 25.04.2009, 16:35

Beitrag von moonshot »

Hallo Ralf,

kam erst eben dazu, Deine Vorschläge auszuprobieren. Der Fehler lag genau hierin:

[quote='r23',index.php?page=Thread&postID=1960#post1960]Ich hoffe, die Session wird nicht in die DB gespeichert?[/quote]
Jetzt geht der Login wieder :)
Vielen Dank für den erstklassigen Support!

Gruß,
Peter
moonshot
Beiträge: 24
Registriert: 25.04.2009, 16:35

Beitrag von moonshot »

P.S. Eine Frage ist noch aufgekommen. Wo lässt sich der Session-Save Path einstellen bzw. ablesen? Ich bekomme noch folgende Meldung im shop:
Warnung: Das Verzeichnis für die Sessions existiert nicht: . Die Sessions werden nicht funktionieren bis das Verzeichnis erstellt wurde!
r23
Beiträge: 2625
Registriert: 18.09.2008, 05:56
Wohnort: Hagen
Kontaktdaten:

Beitrag von r23 »

Hallo,

wenn der Adodb Layer die Session in die Datenbank schreibt(!) *löscht* er die Session - Daten *nie*. Dh. du musst per Hand
die Datenbank pflegen. - sollte man so oder so alle paar Monate mal machen.

Zurück zur Mledung.
Die Meldung stammt aus PHP 4.06 Zeiten unter Windows... Hier fehlte in der PHP.ini der Pfad zu c:/temp für die Session.
Unter Unix gibt es in der Regel kein (nie) Session (speicher) Problem. Wie kommt es trotzdem zu dieser Meldung...

Durch Sicherheitseinstellungen kann man verhindern, dass der Kunde ausserhalb von seinem Bereich Dateien *lesen* darf... darunter
fallen sinnvollerweise auch Session Daten. Dies fürht allerdings auch zu der o.g. Meldung.

Diese Meldung kann man in
~/shop/includes/oos_define.php

Code: Alles auswählen

    define('WARN_SESSION_DIRECTORY_NOT_WRITEABLE', 'false');
ausschalten.

Ob die Session funktioniert solltest du aber dann prüfen.

Wie prüft man die Session. Als nicht angemeldeter Kunde legt man ein Produkt in den Warenkorb und ändert, wenn möglich die Sprache
sollte der Shop auf den Support-Seiten (impressum, Versandkosten, Datenschutz) oder auf der Startseite oder einer Produkt-Seite
den Inhalt vom Warenkorb oder die Sprach einstellung (nicht default) verlieren - so stimmt die Session nicht.

Und nur dann (oder wenn man ein höhes Sicherheitsbedürfnis hat) ändert man

~/shop/admin/includes/
und
~/shop/includes/oos_main.php

Code: Alles auswählen

  if (function_exists('ini_set')) {
    ini_set('arg_separator.output', '&');
  }
und setz mit ini_set den session save path... wenn man ini_set verwenden darf.

Hoffe die Antwort hilft weiter

ralf
moonshot
Beiträge: 24
Registriert: 25.04.2009, 16:35

Beitrag von moonshot »

Hallo,

Danke für die sehr hilfreiche Antwort. :thumbup: Mit Abstellen der Warnmeldung wurde das Problem gelöst. Die Sessiondaten bleiben auf sämtlichen Shopseiten erhalten.

Gruß, Peter
Antworten