Jump to content
xt:Commerce Community Forum

Kunde im falschen Account


bonna

Recommended Posts

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

  • 1 year later...

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 :o

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

  • 2 weeks later...
  • 2 weeks later...

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

  • 2 weeks later...

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

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

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

  • 4 weeks later...

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

Archived

This topic is now archived and is closed to further replies.

×
  • Create New...