Login section, because it determines whether the shop has a login at all. Everything else builds on it.
Reference: Shop configuration shop.config, overview of all sections
Login
Determines whether and when a buyer has to log in, and controls the double opt-in procedure during registration.Login requirement
order-loginrequired is not listed in the previous documentation, but the shop system evaluates it. Any value other than the four listed silently results in no, that is, an open shop. A typo in this parameter therefore opens a closed shop without a warning appearing anywhere.With
LoginMode = start, the shop system reads the cookie shopping cart only after login. A buyer who added something to the cart before logging in will therefore only find it again afterwards.Subshops
Double opt-in
ChangeEmailDoubleOptInSendTo is not listed in the previous documentation. Sending to the old address is the more secure option, because only the owner of the existing mailbox can then confirm the change.Other parameters
None of these parameters is listed in the previous documentation.
RefererURL and IP-Addresses only apply to the first request of a session and, on a match, lead to a notice page rather than a silent rejection.SecureLogin
The most extensive section on this page. It determines how secure a password must be, when access is blocked after failed attempts, how the email address is validated, and it holds the related error messages. On top of that comes the password strength indicator. It rates a password as red, yellow, or green while it is being entered. For this purpose, each threshold exists twice: once as the red threshold, below which the password is rejected, and once as the yellow threshold, from which the indicator switches to green.Password requirements
DenySimplePasswordLevel
This check finds systematic passwords such as1234 or 86420. The level corresponds to the number of permitted one- and two-character steps between consecutive characters. A one-character step lies between ab, ba, 89, or 98; a two-character step between CE, ZX, 24, or 75.
Blocking after failed attempts
The shop system blocks separately by email address and by IP address.Email address validation
basic checks: not empty, no space, exactly one @, at least one dot, the dot comes after the @, and there are at least two characters after the last dot.
syntax includes all checks from basic and additionally checks the part before the @: no two consecutive dots, no dot at the beginning or end, at least one character, and only alphanumeric characters as well as ., -, _, and +. The same applies to the part after the @, without _ and +, and the top-level domain must be between 2 and 10 characters long.
domain includes all checks from basic plus the check of the part before the @ from syntax, and additionally requires an MX or A record to exist for the domain.
UseCaptchaForRequestSetPassword is not listed in the previous documentation. Requesting a new password is a popular way to probe address lists for valid accounts, so captcha protection makes sense here.Error messages
NewPWLength-Txt is not listed in the previous documentation. It states there that the minimum length message is configured in the LoginError-Txt section. Both are true: LoginError-Txt has its own parameter NewPWLength, and in addition there is NewPWLength-Txt here, in which, unlike there, the configured value is inserted.In addition,
~Email-PWSimilaritySignsFaultString~ and ~PWRepeatedSignsFaultString~ are available. They are not filled from the configuration, but only in case of an error, with the characters actually objected to. This lets you tell the buyer not only that something is wrong, but also what.Password strength indicator
For the indicator, each threshold has a second version with-Yellow- in its name. It describes the threshold from which the indicator switches from yellow to green. The thresholds without -Yellow- remain the red threshold, below which the password is rejected.
The associated tags are named as above, with
-Yellow appended:
The spelling
EMail-PWSimilaritySignsFault-Yellow-Value with a capital M is the one the shop system reads. For the parameter without -Yellow-, it is the other way around: there it is named Email-PWSimilaritySignsFault-Value. Since parameter names are compared case-insensitively, both spellings work.SecuredPassword
Determines what happens after a buyer has reset their password via the link in the email.CheckLoginID = yes increases security, because the link alone is then no longer sufficient. Someone who has access to the mailbox but does not know the user ID cannot proceed. The price is an additional input at a moment when the buyer has already forgotten something.AutoLogin
The persistent login. A buyer stays logged in beyond the end of the session and does not need to enter a password on their next visit. Because this is a security risk, the persistent login can be bound to the device, the country, and the IP address, and for particularly sensitive pages, password entry can still be enforced.Basic setting
Critical actions
CriticalActions is a comma-separated list of pages for which the shop system requires password entry despite the persistent login.
Three parameters control exactly when password entry is required:
Binding to device, country, and IP address
The last octet of the IP address is intentionally ignored with
IPDiffers-Allow = no, because many connections receive changing addresses within the same network. Switching connections or switching from mobile data to Wi-Fi still results in a new login.UserData
Determines which particularly sensitive data the shop system stores in the customer account and how the delivery address is preselected for logged-in buyers.All customer data is stored encrypted.
SaveCreditCardData-Allow requires the payment service provider to support tokenization of the card number. The shop then stores not the card number but a placeholder for it.Delivery address preselection
The two parameters apply one after the other. If the buyer has set a default address and
PreSelectDefaultDelivAddr-Allow is set to yes, that address wins and PreSelectLastUsedDelivAddr-Allow no longer has any effect. The second rule only applies when there is no default address.VerifyCustomerData
Determines how strictly the shop system checks customer input for plausibility, and holds the related error messages. Each check has three levels. Withsoft, the buyer is informed of the inconsistency but can still submit the order after confirming. With hard, they must correct it. With no, no check takes place.
In the previous documentation,
AccountNumber has no description; its row in the parameter table is empty. The parameter behaves like the other three and has the same three levels.Error messages
The legacy documentation lists the following messages only in the example block; in the parameter table, some are missing or have no description.IBAN and BIC
The seven IBAN and BIC messages are completely missing from the parameter table in the previous documentation and only appear in the example block there. These messages in particular are worth phrasing individually, because distinguishing between wrong length, wrong checksum, and unsupported country tells the buyer where to look.
WelcomeCookie
The WelcomeBack function. A buyer with an existing customer account is greeted by name on a return visit without being logged in.The cookie contains only a hash value, not the name. The shop system uses it to retrieve the fields from the database. Only the fields listed here are available in the template later, and only fields of the billing address are permitted.
MKForumSSO
Specifies the error template for connecting to portals via single sign-on.The shop system only reads this parameter if the SSO connection is activated for the shop. Without activation, the section has no effect.
Connected external accounts
There is no separate configuration section for the overview of accounts connected to an external service. You simply assign a template in theTemplates section:
CEA- tags. A complete example is available there.
Reference: Templates section, CEA- (Connected external accounts). Guide: External login with Facebook
UserDefList-1 to UserDefList-3
The three sections define entries for selection lists that can be displayed on the billing and delivery address page. They were intended for questions to the buyer, who selects from predefined answers.
Guide: Selection lists for address data