Beim Einrichten eines Kundenkontos überprüft xt:Commerce, ob die angegebene E-Mail Adresse bereits vorliegt. Denn diese ist gewissermaßen der “eindeutige Identifikator” für einen einzelnen Kunden.

E-Mail Dupletten

Leider findet eine solche Überprüfung nicht mehr statt, sobald man einmal eingelogged ist. Das heißt also, dass bei einer nachträglichen Adress-Änderung jede beliebige E-Mail-Adresse benutzt werden kann - unabhängig davon, ob sie im System schon bekannt ist oder nicht.

Die Folgen sind ein bisschen unangenehm …

Ausgangslage:

  • Kunde Meier1
    E-Mail-Adresse: meier1@kunde.de
  • Kunde Müller2
    E-Mail-Adresse: mueller2kunde.de

Beispiel 2:

Wenn Kunde Meier1 seine E-Mail-Adresse in mueller2@kunde.de umändert, hat er Kunde Müller2 ausgesperrt - Denn für die Adresse mueller2@kunde.de funktioniert jetzt nur noch das Passwort von Kunde Meier und der “echte Müller” kann sich mit den ihm bekannten Daten nicht mehr einloggen.

Nicht schön.

Beispiel 2:

Wenn Kunde Müller2 seine E-Mail-Adresse in meier1@kunde.de umändert, hat er nur “sich selbst” ausgesperrt - Denn bei doppelten E-Mail-Adressen wird die Übereinstimmung mit dem Passwort für die erste gefundene E-Mail-Adresse überprüft. Und Kunde Meier1 - der sein Kundenkonto eher als Kunde Müller2 eröffnet hat - kann sich weiterhin mit “seinen” Daten im Shop anmelden.

Auch nicht schön.

Beruhigend ist aber, dass man mit der Methode den Admin nicht “ärgern” kann. Wäre doch ein putziger “Dummerjungen-Streich”: Die E-Mail-Adresse vom Shop-Admin “erahnen” - und ihn aussperren. Haha. Oder einen persönlichen Feind am Einkaufen hindern.

Geht jedoch nur, wenn man eine niedrigere Kunden-ID als derjenige hat, den man ärgern möchte.

 

Abhilfe …?

Coming soon. Vorläufig kann man natürlich die Eingabefelder für E-Mail-Adressen aus dem Template entfernen. (Lösungs-Vorschlag siehe unten …)

Oder aber man “rüstet” wirklich viele System-Dateien nach - Oder … Mit etwas Glück kann man auch eine “Template-Lösung” hinkriegen. Eine erste Idee wäre es, in der boxes.php des Templates etwaige $_POST-Parameter abzufangen - und erst nach “eigener” Überprüfung mit der Funktion xtc_redirect(); weiterzuleiten.

Mit dieser Funktion kann man auch sonst so Einiges anstellen, vielleicht hilft sie ja auch in diesem Fall bei einer eleganteren Lösung als das übliche “Gewühl im System” …

 

 

Nachtrag: Lösung

Es gibt eine Methode, die keine weiteren Änderungen an System-Dateien erfordert. Ein paar Zeilen in die “boxes.php” - und man hat sich viel Gebastel erspart.

Die Idee mit xtc_redirect(); war übrigens Quatsch - denn nach einem Redirect sind alle $_POST-Daten futsch - als hätte man nie ein Formular ausgefüllt. Irgendwie doof, wenn man mordsviel getippt hat und nach einer Fehlermeldung plötzlich alles weg ist …

An dieser Stelle noch mal ein Hinweis am Rande: Die Wahrscheinlichkeit ist zugegebenermaßen nicht besonders groß, dass jemand E-Mail-Adressen von anderen Leuten in ein Shop-System einträgt. Daher ist dieser “Bug” eigentlich keine allzu schlimme Sache. Ich hab’s auch nur deshalb festgestellt, weil ich momentan an einem Shop herumschraube - ein Transfer aus einem anderen System - in dem die Kunden einen “Nickname” haben müssen.

Der Nickname ist u.a. deshalb so wichtig, da xt:Commerce bei “Bewertungen” immer den vollen Namen des Autoren angibt. Und das war wegen Wahrung der Privatsphäre einfach nicht erwünscht. Außerdem gibt’s in dem Shop schon beinahe 20.000 Bewertungen, die “Reviews” sind dort also ein sehr zentraler Bestandteil des Angebots, so dass man dann die Namen nicht einfach komplett ausblenden sollte - Sonst wäre ja plötzlich alles anonym …

 

Prinzip

Alle Benutzerdaten-, Adress-, Kontoneu- etc. Systemdateien von xt:Commerce fangen erst dann an, wirklich etwas an der Datenbank zu tun, wenn $_POST['action'] gesetzt ist und den Wert “process” hat.

  • In der “boxes.php” des aktiven Templates (quasi das erste, was im Shop “stattfindet”) fragen wir einfach nach, ob die wichtigen $_POST-Werte gesetzt sind. So brauchen wir auch nicht lauter unterschiedliche Bereiche zu unterscheiden - Denn wenn es keine Möglichkeit gab, eine E-Mail-Adresse einzugeben, gibt es auch keinen $_POST-Wert dazu.
  • Wenn eine E-Mail-Adresse in $_POST bekannt ist, kann man sich den Wert greifen - und damit alle Überprüfungs-Mechanismen durchführen, die man so braucht.
  • Wenn die Überprüfung ergeben hat, dass es die Adresse schon gibt, muss noch geprüft werden, ob diese bereits existierende Adresse nicht zufällig die des gerade eingeloggten Kunden ist. Denn der soll ja nicht dauernd eine Fehlermeldung bekommen, bloß weil seine eigene Adresse schon bekannt ist.
  • Wenn schließlich feststeht, dass es eine echte “Doppeleingabe” ist, muss $_POST['action'] geleert und die Fehlermeldung initiiert werden.

Da in meinem Fall noch ein paar Dinge mehr als nur die E-Mail-Adresse eine Prüfung benötigen, ist mein Code-Vorschlag vielleicht ein bisschen komplizierter als es ohne die Anforderung, “Nicknames” einzubauen nötig gewesen wäre - Aber wie dem auch sei - Bei mir funktioniert’s: 


function isUniqueData($Value=false,$FieldName=false,$TableName=false) {
	$isUniqueData = true;
	if($Value && $FieldName && $TableName) {
		$UniqueDataQuery = xtc_db_query("select count(*) as total from ".$TableName." where ".$FieldName." = '".$Value."'");
		$UniqueData = xtc_db_fetch_array($UniqueDataQuery);
		if ($UniqueData['total'] > 0)
			$isUniqueData = false;
	}
	return $isUniqueData;
}

function isCustomersOwn($Value=false,$FieldName=false,$TableName=false,$CustomersID=false) {
	$isCustomersOwn = false;
	if(!empty($_SESSION['customer_id']))
		$CustomersID = $_SESSION['customer_id'];
	if($CustomersID && $Value && $FieldName && $TableName) {
		$CustomersDataQuery = xtc_db_query("select ".$FieldName." from ".$TableName." where customers_id = '".$CustomersID."'");
		$CustomersData = xtc_db_fetch_array($CustomersDataQuery);
		if (strtolower($Value) == strtolower($CustomersData[$FieldName]))
			$isCustomersOwn = true;
	}
	return $isCustomersOwn;
}

$ErrorFlag = false;

if (!empty($_POST)) {
	if (isset($_POST['email_address'])) {
		require_once (DIR_FS_INC.'xtc_validate_email.inc.php');
		if (strlen($_POST['email_address']) < ENTRY_EMAIL_ADDRESS_MIN_LENGTH) {
				$ErrorFlag = true;
				$messageStack->add('error', ENTRY_EMAIL_ADDRESS_ERROR);
		} elseif (xtc_validate_email($_POST['email_address']) == false) {
				$ErrorFlag = true;
				$messageStack->add('error', ENTRY_EMAIL_ADDRESS_CHECK_ERROR);
		} elseif (!isUniqueData($_POST['email_address'],'customers_email_address',TABLE_CUSTOMERS)) {
			if(!isCustomersOwn($_POST['email_address'],'customers_email_address',TABLE_CUSTOMERS)) {
				$ErrorFlag = true;
				$messageStack->add('error', ENTRY_EMAIL_ADDRESS_ERROR_EXISTS);
			}
		}
	}
	if($ErrorFlag) {
		unset($_POST['action']);
		$smarty->assign('error', $messageStack->output('error'));
	}
}

Datt Janze gehört in die “boxes.php” - am besten direkt an den Anfang.

Hinweis: xt:Commerce überprüft von Haus aus nur, ob die eingegebene E-Mail-Adresse für Accounts mit Type ‘0′ mehrfach vorhanden ist.

xtc_db_query("select count(*) as total from ".TABLE_CUSTOMERS." where customers_email_address = '".xtc_db_input($email_address)."' and account_type = '0'");

Das wird wohl für “Gastkonten” gedacht sein, die ja meistens ohnehin nicht dauerhaft gespeichert werden …

Der Funktion isUniqueData(); im oben gezeigten Lösungs-Beispiel ist der “Account Type” bei der Prüfung wurscht - In meinem Fall war das nötig um zu vermeiden, dass “Gastkunden” unter einem bereits bestehenden Nickname irgendwelche Bewertungen schreiben können …

 

 

Die in diesem Beitrag beschriebene Änderung ist für xt:Commerce 3.04 SP2.1 gedacht und auch nur mit diesem System getestet. Da es sich allerdings um einen Shop mit importierten Daten handelt, der etliche hinzugebaute Erweiterungen hat, könnten in “normalen” Konfigurationen Fehler auftreten.

Bitte beachten Sie auch unbedingt die allgemeinen Hinweise zur Verwendung hier veröffentlichter Code-Beispiele - und probieren Sie solche Eingriffe bitte immer zuerst mit einem Test-System aus!