bonna Posted June 14, 2007 Report Share Posted June 14, 2007 Hallo, liebe XTC-ler, ein Kunde ist nach korrekter Anmeldung im Account eines anderen Kunden gelandet und hat dann die Bestellung abgebrochen, nach Neuanmeldung war er dann richtig. Nun bekomme ich eine Bestellung eines anderen Kunden mit den Adressdaten des Kunden, der vormals im falschen Account gelandet ist und habe nur die Daten des Kunden, der nichts bestelt hat. Vor ca. einem Monat wollte ich einem Kunden einen Account einrichten und landete beim Anmelden im Account eines anderen, bestehenden Kunden. Wie kann das sein?? sind evtl. Rechte falsch definiert? Uwe Link to comment Share on other sites More sharing options...
brischt Posted September 25, 2008 Report Share Posted September 25, 2008 Hallo Uwe, ich habe vereinzelt dasselbe Problem. Hast Du zufällig zwischenzeitlich etwas dazu herausgefunden? Wäre Dir für Infos sehr dankbar. Viele Grüße, Roland Link to comment Share on other sites More sharing options...
Bloodred Horizon Rec. Posted September 26, 2008 Report Share Posted September 26, 2008 Haben das selbe Problem, hab auf einmal Bestellungen von Kunden bekommen die nicht bestellt haben. Die richtigen Besteller haben sich dann beschwert daß der Shop nicht sicher sei usw., weil Ihre Bestellung mti den Daten anderer versehen ist... LG Jens Link to comment Share on other sites More sharing options...
brischt Posted September 26, 2008 Report Share Posted September 26, 2008 Hallo Jens, versuch es mal mit den in diesem Thread empfohlenen Einstellungen. Vor allem sollten glaube ich die Sessions in der DB gespeichert werden statt in Dateien. Wir haben gestern die Konfiguration wie dort beschrieben umgestellt, und zumindest bisher trat das Problem nicht mehr auf, toi toi toi Viele Grüße, Roland Haben das selbe Problem, hab auf einmal Bestellungen von Kunden bekommen die nicht bestellt haben. Die richtigen Besteller haben sich dann beschwert daß der Shop nicht sicher sei usw., weil Ihre Bestellung mti den Daten anderer versehen ist... LG Jens Link to comment Share on other sites More sharing options...
Bloodred Horizon Rec. Posted October 10, 2008 Report Share Posted October 10, 2008 Habe keine Rechte diesen Thread zu lesen :-( Link to comment Share on other sites More sharing options...
andy79 Posted October 23, 2008 Report Share Posted October 23, 2008 Hallo Jens, versuch es mal mit den in diesem Thread empfohlenen Einstellungen. Viele Grüße, Roland Hallo, ich habe auch das Problem, kann aber diesen Threat nicht öffnen. Wäre super wenn jemand die notwendigen Änderungen nochmal posten würden. vielen Dank,, Andy Link to comment Share on other sites More sharing options...
EG@YHD Posted October 24, 2008 Report Share Posted October 24, 2008 Könnte das hier stehen... Deshalb lasse ich die Session Daten in die Datenbank speichern. In den Dateien xtcommerce/includes/configure.php xtcommerce/includes/configure.org.php xtcommerce/admin/includes/configure.php xtcommerce/admin/includes/configure.org.php kannst du das einstellen. define('STORE_SESSIONS', 'mysql'); // leave empty '' for default handler or set to 'mysql' Link to comment Share on other sites More sharing options...
roman.eberle Posted November 5, 2008 Report Share Posted November 5, 2008 hi, wir haben hier auch diverse xtCommerce probleme - falsche artikel in der bestellung, falsche adressen in der bestellung. die besagte einstellung sessions in der mysql zu speichern hat offenbar keinen erfolg gehabt, unser kunde meldet weiterhin fehler und beschwerden. nun haben wir hier wiederholte table crashes in der mysql, das ist natuerlich weniger gut, vor allem auch zur fehlerlokalisierung. kann jemand einen zusammenhang herstellen? verursacht xtCommerce die tablecrashes? oder ist das eine ganz andere baustelle? hat jemand den fehler bei sich lokalisieren koennen? evtl. ist dieser mysql bug interessant, scheinbar gibts probleme mit 64bit architekturen (so wie unser server): http://bugs.mysql.com/bug.php?id=34540 betreibt ihr auch 64bit maschinen? gruss und dank, roman Link to comment Share on other sites More sharing options...
roman.eberle Posted November 6, 2008 Report Share Posted November 6, 2008 hm, habt ihr mal eure server mit mcelog gecheckt? auf unserem server werden Machine Check Events geloggt, diese kann man mit z.b. 'mcelog > logfile.txt' auslesen. (tipp: man page zu mcelog vor benutzung lesen!) das sieht momentan etwa so aus: MCE 0 HARDWARE ERROR. This is *NOT* a software problem! Please contact your hardware vendor CPU 0 4 northbridge TSC 1aa7acceac00f ADDR 11b700000 Northbridge GART error bit61 = error uncorrected TLB error 'generic transaction, level generic' STATUS a40000000005001b MCGSTATUS 0 Resolving address 11b700000 using SMBIOS No matching memory address found for 11b700000 in SMBIOS MCE 1 HARDWARE ERROR. This is *NOT* a software problem! Please contact your hardware vendor CPU 0 4 northbridge TSC 1ad7ebfa5b132 ADDR 11b700000 Northbridge GART error bit61 = error uncorrected TLB error 'generic transaction, level generic' STATUS a40000000005001b MCGSTATUS 0 Resolving address 11b700000 using SMBIOS No matching memory address found for 11b700000 in SMBIOS MCE 2 (...) diese machine check events wurden in den letzten 2 tagen geloggt. eindeutiger hardwarefehler? regards, ro Link to comment Share on other sites More sharing options...
roman.eberle Posted November 6, 2008 Report Share Posted November 6, 2008 nachtrag: desweiteren ist mir aufgefallen dass in unserer xtCommerce datenbank (die nun die sessions verwaltet - siehe konfiguration oben im thread) in der xt_sessions tabelle eigenartige session keys vergeben werden, statt den ueblichen kryptischen strings manchmal session keys wie 'source', 'function.mysql-query', 'function.unlink', ... ausserdem gelegentliche segmentation faults des apache2 (phpinfo(): Client API version 5.0.34) Link to comment Share on other sites More sharing options...
roman.eberle Posted December 2, 2008 Report Share Posted December 2, 2008 Nachtrag: Wir haben das Problem mittlerweile so geloest: - Sessionverwaltung auf MYSQL umstellen, wie zuvor beschrieben - dadurch werden benutzerdefinierte Funktionen zum Lesen und Schreiben der Sessions (Session-Keys) verwendet, siehe Datei .../xtcommerce/includes/functions/sessions.php - in den Funktionen _sess_read(), _sess_write() und _sess_destroy() eine Abfrage eingefuegt, die bei zu kurzen ( < 31 Zeichen ) Sessionkeys die Funktion mit return false (bzw. return '') beendet. Dadurch werden zwar einige Sessionkeys verworfen, aber solange der Benutzer auf der Website ein paar mal klickt erhaelt er genuegend Moeglichkeiten einen 'echten', unverwechselbaren Sessionkey zu erhalten. In jedem Fall besser als ein 'verwechselbarer', korrupter Sessionkey wie 'source', etc. :-) Desweiteren: im Block... if (STORE_SESSIONS == 'mysql') { ...die Zeile... @ini_set('session.save_handler', 'user'); eingefuegt, und den Rueckgabewert von _sess_read() korrigiert: return ''; ...statt return false; Seitdem haben wir keine Beschwerden mehr seitens unserer Kunden. Ein Server-Umzug mit den entsprechenden Software-Updates ist fuer einen spaeteren Zeitpunkt geplant, auch damit der Fehler dann hoffentlich ursaechlich behoben ist, und nicht nur 'kosmetisch'. Gruss! Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.