Zum Hauptinhalt springen
Ob ein Käufer sich überhaupt anmelden muss, wie sicher sein Passwort sein soll, wie lange er angemeldet bleibt und was der Shop von ihm speichert: Diese Fragen beantworten die Abschnitte auf dieser Seite. Sie hängen enger zusammen, als ihre Trennung in der Konfiguration vermuten lässt. Der Einstieg ist der Abschnitt Login, denn er entscheidet, ob es im Shop überhaupt eine Anmeldung gibt. Alles Weitere baut darauf auf. Referenz: Shopkonfiguration shop.config, Übersicht aller Abschnitte

​
Login

Legt fest, ob und wann sich ein Käufer anmelden muss, und steuert das Double-OptIn-Verfahren bei der Registrierung.

​
Anmeldepflicht

Jeder andere als die vier genannten Werte führt stillschweigend zu no, also zu einem offenen Shop. Ein Tippfehler in diesem Parameter öffnet damit einen geschlossenen Shop, ohne dass irgendwo eine Warnung erscheint. Bei LoginMode = start liest das Shopsystem den Cookie-Warenkorb erst nach der Anmeldung ein. Ein Käufer, der vor dem Anmelden etwas in den Warenkorb gelegt hatte, findet es also erst danach wieder.

​
Subshops

SubshopLogin-Allow wirkt ausschließlich auf Neuanmeldungen. Bestehende Konten bekommen die zusätzlichen Subshops nicht nachträglich zugeteilt. Der Parametername legt das nicht nahe, das Verhalten ist aber so gewollt.

​
Double-OptIn

Eine E-Mail-Adresse, zu der ein nicht bestätigtes Konto existiert, lässt sich derzeit nicht erneut verwenden. Der Käufer kommt dann nur mit einer anderen Adresse weiter. Setzen Sie NewCustomerResendDoubleOptInMail-Allow auf yes, damit er die Aktivierungsmail wenigstens erneut anfordern kann.
Der Versand an die alte Adresse ist die sicherere Variante, denn nur der Inhaber des bestehenden Postfachs kann die Änderung dann bestätigen.

​
Weitere Parameter

RefererURL und IP-Addresses greifen nur beim ersten Aufruf einer Sitzung und führen bei einem Treffer zu einer Hinweisseite, nicht zu einer stillen Ablehnung.
Der veraltete Parameter DisableNewCustomerDoubleOptIn wird nur dann noch ausgewertet, wenn NewCustomerResendDoubleOptInMail-Allow in der Konfiguration gar nicht vorkommt. Sobald dieser Parameter gesetzt ist, auch auf no, ignoriert das Shopsystem den alten Parameter. Verwenden Sie statt DisableNewCustomerDoubleOptIn den Wert off in NewCustomerDoubleOptInMode.
Wegweiser: Anmeldung/Registrierung, Double-OptIn, Bestellmenge eines Produkts, Subshop-übergreifende Logins, Sicheres Anmeldeverfahren

​
SecureLogin

Der umfangreichste Abschnitt dieser Seite. Er legt fest, wie sicher ein Passwort sein muss, wann ein Zugang nach Fehlversuchen gesperrt wird, wie die E-Mail-Adresse geprüft wird, und er hält die zugehörigen Fehlermeldungen. Dazu kommt die Passwortampel. Sie bewertet ein Passwort schon während der Eingabe mit rot, gelb oder grün. Dafür gibt es jeden Grenzwert zweimal: einmal als Rot-Grenze, unterhalb derer das Passwort abgelehnt wird, und einmal als Gelb-Grenze, ab der die Ampel auf Grün springt.
Der Parameter für die Mindestlänge heißt im Shopsystem PWMinLenght-Value, mit vertauschten Buchstaben. Das Shopsystem liest diese Schreibweise zuerst und fällt nur dann auf das korrekt geschriebene PWMinLength-Value zurück, wenn die erste Zeile fehlt. Beide Schreibweisen funktionieren also, aber nicht gleichzeitig: Steht die falsch geschriebene Zeile in der Konfiguration, dann gewinnt sie. Dasselbe gilt für PWMinLenght-Yellow-Value.

​
Anforderungen an das Passwort

Werte außerhalb des zulässigen Bereichs schalten die Prüfung ab, statt auf die Grenze gezogen zu werden. Bei PWRepeatedSignsFault-Value = 1 oder = 20 findet also keine Prüfung statt. Eine Ausnahme ist die Mindestlänge: Sie wird bei 0 auf 6 gesetzt und bei mehr als 64 auf 64 gekürzt.

​
DenySimplePasswordLevel

Diese Prüfung findet systematische Passwörter wie 1234 oder 86420. Das Level entspricht der Anzahl erlaubter Ein- und Zweizeichenabstände zwischen aufeinanderfolgenden Zeichen. Ein Einzeichenabstand liegt zwischen ab, ba, 89 oder 98, ein Zweizeichenabstand zwischen CE, ZX, 24 oder 75.
Level 1 bietet die höchste Sicherheit, schränkt die Passwortwahl aber so stark ein, dass sie dem durchschnittlichen Käufer kaum noch zu erklären ist. Die Altdokumentation empfiehlt daher 0, also die Prüfung abzuschalten. Wer sie einsetzen will, liegt mit 3 oder 4 bei hoher Sicherheit und noch erträglicher Bedienbarkeit.

​
Sperren nach Fehlversuchen

Das Shopsystem sperrt getrennt nach E-Mail-Adresse und nach IP-Adresse.

​
Prüfung der E-Mail-Adresse

basic prüft: nicht leer, kein Leerzeichen, genau ein @, mindestens ein Punkt, der Punkt steht hinter dem @, und hinter dem letzten Punkt stehen mindestens zwei Zeichen. syntax enthält alle Prüfungen aus basic und zusätzlich für den Teil vor dem @: keine zwei Punkte hintereinander, kein Punkt am Anfang oder Ende, mindestens ein Zeichen, und nur alphanumerische Zeichen sowie ., -, _ und +. Für den Teil hinter dem @ gilt dasselbe ohne _ und +, und die Top-Level-Domain muss zwischen 2 und 10 Zeichen lang sein. domain enthält alle Prüfungen aus basic samt der Prüfung des Teils vor dem @ aus syntax und verlangt zusätzlich, dass für die Domain ein MX- oder A-Eintrag existiert.
Nur domain prüft, ob es zu der Adresse überhaupt einen erreichbaren Mailserver gibt. Ohne diese Prüfung kann es passieren, dass weder die Aktivierungsmail noch die Bestellbestätigung zustellbar ist, der Käufer das aber erst merkt, wenn er sie vermisst.EmailCheckMode wird nicht berücksichtigt, wenn für das Feld E-Mail der Rechnungs- oder Lieferadresse ein InputCheck vom Typ Email definiert ist. Dann gilt ausschließlich dieser InputCheck. Wenn Sie hier einen anderen Wert als domain setzen wollen, prüfen Sie zuerst, ob ein solcher InputCheck existiert, und entfernen Sie ihn.
Das Anfordern eines neuen Passworts ist ein beliebter Weg, um Adressbestände auf gültige Konten abzuklopfen, deshalb ist ein Captchaschutz an dieser Stelle sinnvoll.

​
Fehlermeldungen

Dort heißt es, die Meldung zur Mindestlänge werde im Abschnitt LoginError-Txt konfiguriert. Beides stimmt: LoginError-Txt hat einen eigenen Parameter NewPWLength, und zusätzlich gibt es hier NewPWLength-Txt, in dem anders als dort der konfigurierte Wert eingesetzt wird. In diese Meldungen setzt das Shopsystem die konfigurierten Werte ein. Verfügbar sind:
Das Shopsystem ersetzt eines dieser Tags nur dann, wenn der zugehörige Parameter größer 0 ist. Steht der Parameter auf 0 und das Tag trotzdem im Text, dann liest der Käufer das Tag im Klartext. Nehmen Sie das Tag also aus der Meldung heraus, sobald Sie die zugehörige Prüfung abschalten.
Zusätzlich stehen ~Email-PWSimilaritySignsFaultString~ und ~PWRepeatedSignsFaultString~ zur Verfügung. Sie werden nicht aus der Konfiguration gefüllt, sondern erst im Fehlerfall mit den tatsächlich beanstandeten Zeichen. Damit sagen Sie dem Käufer nicht nur, dass etwas nicht passt, sondern auch was.

​
Passwortampel

Für die Ampel gibt es zu jedem Grenzwert eine zweite Fassung mit -Yellow- im Namen. Sie beschreibt die Grenze, ab der die Ampel von Gelb auf Grün springt. Die Grenzwerte ohne -Yellow- bleiben die Rot-Grenze, unterhalb derer das Passwort abgelehnt wird. Die zugehörigen Tags heißen wie oben, ergänzt um -Yellow:
Das Tag für die Sperrliste heißt ~PWBlackListedString-Yellow~, also in der Einzahl, während der Parameter PWBlackListedStrings-Yellow-List in der Mehrzahl steht. Wer das Tag in der Mehrzahl schreibt, bekommt es im Klartext angezeigt.Die Gelb-Grenze darf der Rot-Grenze nicht widersprechen. Eine Gelb-Grenze, die unter der Rot-Grenze liegt, ergibt eine Ampel, die grün zeigt, obwohl das Passwort abgelehnt wird. Das Shopsystem prüft das nicht.
Die Schreibweise EMail-PWSimilaritySignsFault-Yellow-Value mit großem M ist die, die das Shopsystem liest. Beim Parameter ohne -Yellow- ist es umgekehrt, dort heißt er Email-PWSimilaritySignsFault-Value. Da Parameternamen ohne Rücksicht auf Groß- und Kleinschreibung verglichen werden, funktionieren beide Schreibweisen. Wegweiser: Sicheres Anmeldeverfahren, Prüfung der E-Mail-Adresse. Referenz: Abschnitt InputCheck, Abschnitt LoginError-Txt

​
SecuredPassword

Legt fest, was passiert, nachdem ein Käufer sein Passwort über den Link aus der E-Mail neu gesetzt hat.
CheckLoginID = yes erhöht die Sicherheit, denn der Link allein genügt dann nicht mehr. Wer Zugriff auf das Postfach hat, aber die Benutzerkennung nicht kennt, kommt damit nicht weiter. Der Preis ist eine zusätzliche Eingabe in einem Moment, in dem der Käufer ohnehin schon etwas vergessen hat. Wegweiser: Passwort vergessen

​
AutoLogin

Der dauerhafte Login. Ein Käufer bleibt über das Ende der Sitzung hinaus angemeldet und muss beim nächsten Besuch kein Passwort eingeben. Weil das ein Sicherheitsrisiko ist, lässt sich der dauerhafte Login an das Gerät, das Land und die IP-Adresse binden, und für besonders schützenswerte Seiten lässt sich die Passworteingabe trotzdem erzwingen.

​
Grundeinstellung

​
Kritische Aktionen

CriticalActions ist eine kommaseparierte Liste von Seiten, bei denen das Shopsystem trotz dauerhaftem Login eine Passworteingabe verlangt. Wann genau die Passworteingabe greift, steuern drei Parameter:
CriticalActions ist im Standard leer. Ohne Einträge kommt ein dauerhaft angemeldeter Käufer ohne weitere Prüfung bis zur Bestellübersicht. Nehmen Sie mindestens UserAccount und PlaceOrder auf, denn dort stehen Adresse und Zahlungsdaten.

​
Bindung an Gerät, Land und IP-Adresse

Bei CountryDiffers-Allow = no scheitert der dauerhafte Login auch dann, wenn gar kein Land ermittelt werden konnte. Rechnen Sie also damit, dass ein Teil Ihrer Käufer sich trotz dauerhaftem Login wieder anmelden muss.
Das letzte Oktett der IP-Adresse bleibt bei IPDiffers-Allow = no absichtlich unberücksichtigt, weil viele Anschlüsse innerhalb desselben Netzes wechselnde Adressen bekommen. Ein Wechsel des Anschlusses oder vom Mobilfunk ins WLAN führt trotzdem zu einer neuen Anmeldung. Wegweiser: Dauerhafter Login

​
UserData

Legt fest, welche besonders schützenswerten Daten das Shopsystem im Kundenkonto speichert und wie die Lieferadresse für angemeldete Käufer vorausgewählt wird.
Alle Kundendaten werden verschlüsselt gespeichert. SaveCreditCardData-Allow setzt voraus, dass der Zahlungsdienstleister eine Tokenisierung der Kartennummer unterstützt. Im Shop liegt dann nicht die Kartennummer, sondern ein Platzhalter dafür.

​
Vorauswahl der Lieferadresse

Die beiden Parameter greifen nacheinander. Hat der Käufer eine Standardadresse festgelegt und steht PreSelectDefaultDelivAddr-Allow auf yes, dann gewinnt diese, und PreSelectLastUsedDelivAddr-Allow hat keine Wirkung mehr. Erst ohne Standardadresse kommt die zweite Regel zum Zug. Wegweiser: Zahlungsart “Kreditkarte”, Lastschrift und Bankverbindung abfragen, Zwangsänderung des Passworts bei Neukunden, Mehrfachkonten, Standard-Lieferadresse festlegen

​
VerifyCustomerData

Legt fest, wie streng das Shopsystem Kundeneingaben auf Plausibilität prüft, und hält die zugehörigen Fehlermeldungen. Jede Prüfung kennt drei Stufen. Bei soft erfährt der Käufer vom Widerspruch, kann die Bestellung nach Bestätigung aber trotzdem abschicken. Bei hard muss er korrigieren. Bei no findet keine Prüfung statt.
Der Parameter verhält sich wie die anderen drei und kennt dieselben drei Stufen.
hard bei FirstName und Zip führt dazu, dass Käufer mit einem ungewöhnlichen Vornamen oder einer frisch vergebenen Postleitzahl nicht bestellen können. Beide Prüfungen stützen sich auf Datenbestände, die nie vollständig sind. soft ist deshalb die sichere Wahl.

​
Fehlermeldungen

Die Altdokumentation führt die folgenden Meldungen nur im Beispielblock auf, in der Parametertabelle fehlen sie teils oder stehen ohne Beschreibung da.

​
IBAN und BIC

Gerade diese Meldungen lohnen eine eigene Formulierung, denn die Unterscheidung zwischen falscher Länge, falscher Prüfsumme und nicht unterstütztem Land sagt dem Käufer, wo er suchen muss. Wegweiser: Prüfung von Kundendaten festlegen

​
WelcomeCookie

Die WelcomeBack-Funktion. Ein Käufer mit bestehendem Kundenkonto wird beim erneuten Besuch mit Namen begrüßt, ohne dass er angemeldet ist.
Im Cookie steht nur ein Hashwert, nicht der Name. Die Felder holt das Shopsystem damit aus der Datenbank. Nur die hier aufgeführten Felder stehen später im Template zur Verfügung, und ausschließlich Felder der Rechnungsadresse sind zulässig.
Die Begrüßung mit Namen setzt voraus, dass der Besucher dem Cookie zugestimmt hat. Registrieren Sie den Cookie im Abschnitt AgreementCookies, sonst wird er nicht gesetzt.
Wegweiser: WelcomeBack-Funktion. Referenz: WC- (WelcomeBack-Funktion)

​
MKForumSSO

Hinterlegt das Fehler-Template für die Anbindung an Portale über Single Sign-on.
Das Shopsystem liest diesen Parameter nur, wenn die SSO-Anbindung für den Shop freigeschaltet ist. Ohne Freischaltung bleibt der Abschnitt wirkungslos. Wegweiser: Schnittstelle zu Portalen

​
Verbundene externe Konten

Für die Übersicht der mit einem externen Dienst verbundenen Konten gibt es keinen eigenen Konfigurationsabschnitt. Sie weisen lediglich im Abschnitt Templates ein Template zu:
Den Inhalt des Templates bauen Sie mit den CEA-Tags. Ein vollständiges Beispiel steht dort. Referenz: Abschnitt Templates, CEA- (Verbundene externe Konten). Wegweiser: Externes Login mit Facebook

​
UserDefList-1 bis UserDefList-3

Diese Funktion ist veraltet und wird nicht mehr unterstützt. Für neue Shops verwenden Sie stattdessen die Auswahllisten der Adressdatenfelder.
Die drei Abschnitte definieren Einträge für Auswahllisten, die auf der Seite für Rechnungs- und Lieferadresse angezeigt werden können. Gedacht waren sie für Fragen an den Käufer, die er aus vorgegebenen Antworten auswählt.
Die Auswahl des Käufers wird zwar in die Bestelldaten übergeben, aber nicht dauerhaft in den Kundendaten gespeichert. Bei der nächsten Bestellung steht die Liste wieder auf der Vorgabe.
Wegweiser: Auswahllisten der Adressdaten