> ## Documentation Index
> Fetch the complete documentation index at: https://dokumentation.websale.de/llms.txt
> Use this file to discover all available pages before exploring further.

# Customer, login and account

> Building login and registration in the template: input fields for email address and password, the combined login, persistent login, confirming the email address and the links into the customer account.

Almost all tags on this page build form fields. That sounds monotonous, but it is the reason why they are so easy to learn: they follow the same three-part pattern almost without exception. Once you have understood it, you can write any field on this page without reading the individual description.

That is why this pattern comes first. It is followed by the forms built from it, from the simple login through the combined login in the order process to the confirmation of the email address. At the end are the links that lead from the shop into the customer account.

Reference: The introduction to the prefix `WS-` and the overview of the eight pages are on Shop, page and technology

## The three-part pattern

Almost every input field comes with three tags.

| Suffix | Returns | Belongs in |
| - | - | - |
| none | the value entered so far | the `value` attribute |
| `_input` | the HTML name of the field | the `name` attribute |
| `_error` | the error style suffix | the `class` attribute |

```html theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<input type="text"
       name="~WS-Email_input~"
       value="~WS-Email~"
       class="eingabe~WS-Email_error~">
```

> [!NOTE]
>
> As a single tag, the suffix `_error` returns the string `_error` and nothing else. Append it to a class name, and the class is called `eingabe_error` in case of an error and `eingabe` otherwise. This lets you design the error display entirely via CSS, without a second area tag in the template.

> [!NOTE]
>
> Every `_error` tag also works as an area tag, which applies when the input is incorrect. This is the way to show an error message in words next to the field.

```html theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
{WS-Email_error}
   <p class="fehler">Bitte geben Sie eine gültige E-Mail-Adresse ein.</p>
{/WS-Email_error}
```

> [!WARNING]
>
> The value tags return the **most recently entered** value so that the buyer does not have to retype everything after an error. This also applies to password fields. For a password field, consider whether you really want to write the value back, or whether an empty field is the better choice.

## Login and registration

The same fields serve different purposes depending on the process. This is the most common stumbling block on the login template.

| Tag | When logging in | When changing |
| - | - | - |
| `WS-Email` | the email address of the existing customer | the previous email address |
| `WS-NewEmail` | the email address of the new customer | the new email address |
| `WS-EmailAgain` | – | the repetition of the new email address |
| `WS-PW` | the password of the existing customer | the previous password |
| `WS-NewPW` | the password of the new customer | the new password |
| `WS-PWAgain` | the repetition for the new customer | the repetition of the new password |
| `WS-UserID` | the user ID, if the shop works with one | – |

```html theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<form action="~FORM-LoginKnownUser~" method="post">
   <input type="text"
          name="~WS-Email_input~"
          value="~WS-Email~"
          class="eingabe~WS-Email_error~">

   <input type="password"
          name="~WS-PW_input~"
          maxlength="64"
          class="eingabe~WS-PW_error~">

   <input type="submit" value="Anmelden">
</form>
```

> [!WARNING]
>
> The example on the previous page for `WS-PW` shows an `input` element with `type="text"`. A password field must have `type="password"`, otherwise the password is visible on the screen. The examples for `WS-NewPW` and `WS-PWAgain` do it correctly. The corrected version is shown above.

> [!NOTE]
>
> The difference between `WS-Email` and `WS-NewEmail` is not old versus new, but existing customer versus new customer. On a template that covers both cases, you need both fields, and they must not carry the same `name` attribute.

> [!NOTE]
>
> `WS-UserID` belongs to shops in which the buyer does not log in with their email address but with an assigned ID. This is common above all in the B2B area. In a shop without this login type, the three tags simply remain unused.

### The password strength indicator

```html theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<body>
   ~WS-SecureLoginConfigurationJS~
   ...
</body>
```

> [!NOTE]
>
> `WS-SecureLoginConfigurationJS` outputs the content of the `secure login` section of the shop configuration as a script in the page. This tells the password strength indicator in the browser which rules apply to a valid password. Without this tag, the indicator cannot check anything.

> [!NOTE]
>
> The tag belongs exclusively on the templates on which the buyer sets a new password, that is, on registration and on password change. It has no place on the ordinary login page.

### Forgotten password

```html theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<form action="~FORM-RequestPW~" method="post">
   <input type="text" name="~WS-Email_input~" value="~WS-Email~">
   ~WS-PWRequestZip~
   <input type="submit" value="Passwort zusenden">
</form>
```

> [!NOTE]
>
> `WS-PWRequestZip` generates a ready-made input field for the postal code. You only write the tag, not the surrounding `input` element. The additional query prevents someone from requesting a password using only a guessed email address.

> [!NOTE]
>
> `WS-RequestPWLink` generates the link to the login page for this purpose. It behaves like `WS-LoginLink`, but does not tie the process to the order process. The tag exists in the shop system but is not described in the previous documentation.

## Staying logged in

A buyer who has to type their password on every visit comes back less often. Two checkboxes offer them the option to stay logged in, and they differ in one important point.

| Tag | Automatic login | Before critical actions |
| - | - | - |
| `WS-StaySignedIn_input` | yes | password must be re-entered |
| `WS-StayFullySignedIn_input` | yes | no re-entry needed |

```html theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<form action="~FORM-QuickLogin~" method="post">
   ...
   <label>
      <input type="checkbox" name="~WS-StaySignedIn_input~">
      Angemeldet bleiben
   </label>
</form>
```

> [!WARNING]
>
> Both tags must be placed **inside** the login form, that is, inside `FORM-LoginNewUser`, `FORM-LoginStart`, `FORM-QuickLogin`, `FORM-CombinedLogin` or another login form. Outside it, they do generate a field name, but it is never submitted.

> [!WARNING]
>
> Only offer `WS-StayFullySignedIn_input` if you know that buyers shop on private devices. In a shop that is also used on shared computers, `WS-StaySignedIn_input` is the right choice, because there the password prompt before critical actions protects the account.

### Re-authentication before critical actions

```html theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
{WS-UserRequiresReAuthForCritAction}
   <p>Bitte bestätigen Sie zur Sicherheit noch einmal Ihr Passwort.</p>
   <form action="~FORM-ReauthUser~" method="post">
      <input type="password" name="~WS-PW_input~" class="eingabe~WS-PW_error~">
      <input type="submit" value="Bestätigen">
   </form>
{/WS-UserRequiresReAuthForCritAction}

{!WS-UserRequiresReAuthForCritAction}
   ... die eigentliche Seite ...
{/!WS-UserRequiresReAuthForCritAction}
```

> [!NOTE]
>
> `WS-UserRequiresReAuthForCritAction` applies when three things are true at the same time: the buyer was logged in automatically, they have not yet entered a password in this session, and the page meets one of the configured criteria for a critical action.

> [!WARNING]
>
> Put sensitive content such as address data, bank details or the order history in the **negative** area tag. Otherwise an automatically logged-in buyer sees it without having confirmed their password. The tag is permitted on all templates precisely so that you can use it wherever it is needed.

## The combined login

In the order process, the buyer is presented with three options: log in as an existing customer, register as a new customer, or order as a guest. Because this takes place in one form, there is a dedicated tag family with a regular structure.

**The selection** consists of a name and, for each option, a value and a marker:

| Tag | Returns |
| - | - |
| `WS-CombinedLogin_radioname` | the common HTML name of the radio buttons |
| `WS-CombinedLogin_radiovalue_knownUser` | the value for logging in as an existing customer |
| `WS-CombinedLogin_radiovalue_newUser` | the value for new registration |
| `WS-CombinedLogin_radiovalue_noLogin` | the value for ordering without an account |
| `WS-CombinedLogin_radioselected_knownUser` | `_checked` if this option is selected |
| `WS-CombinedLogin_radioselected_newUser` | the same for new registration |
| `WS-CombinedLogin_radioselected_noLogin` | the same for ordering without an account |

**The fields** again follow the three-part pattern:

| Field | Value | Name | Error |
| - | - | - | - |
| Email address | `WS-CombinedLogin_eMail` | `WS-CombinedLogin_eMail_input` | `WS-CombinedLogin_eMail_error` |
| Existing customer password | `WS-CombinedLogin_PWknownUser` | `WS-CombinedLogin_PWknownUser_input` | `WS-CombinedLogin_PWknownUser_error` |
| New customer password | `WS-CombinedLogin_PWnewUser` | `WS-CombinedLogin_PWnewUser_input` | `WS-CombinedLogin_PWnewUser_error` |
| New customer repetition | `WS-CombinedLogin_PWAgainnewUser` | `WS-CombinedLogin_PWAgainnewUser_input` | `WS-CombinedLogin_PWAgainnewUser_error` |

```html theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<form action="~FORM-CombinedLogin~" method="post">
   <input type="text"
          name="~WS-CombinedLogin_eMail_input~"
          value="~WS-CombinedLogin_eMail~"
          class="eingabe~WS-CombinedLogin_eMail_error~">

   <label>
      <input type="radio"
             name="~WS-CombinedLogin_radioname~"
             value="~WS-CombinedLogin_radiovalue_knownUser~"
             ~WS-CombinedLogin_radioselected_knownUser~>
      Ich habe bereits ein Konto
   </label>
   {WS-CombinedLogin_radioselected_knownUser}
      <input type="password"
             name="~WS-CombinedLogin_PWknownUser_input~"
             class="eingabe~WS-CombinedLogin_PWknownUser_error~">
   {/WS-CombinedLogin_radioselected_knownUser}

   <label>
      <input type="radio"
             name="~WS-CombinedLogin_radioname~"
             value="~WS-CombinedLogin_radiovalue_newUser~"
             ~WS-CombinedLogin_radioselected_newUser~>
      Ich möchte ein Konto anlegen
   </label>

   <label>
      <input type="radio"
             name="~WS-CombinedLogin_radioname~"
             value="~WS-CombinedLogin_radiovalue_noLogin~"
             ~WS-CombinedLogin_radioselected_noLogin~>
      Ohne Konto bestellen
   </label>

   <input type="submit" value="Weiter">
</form>
```

> [!NOTE]
>
> The email address appears only once in the form, because it is needed in all three cases. Only the password fields differ.

> [!NOTE]
>
> As single tags, the `_radioselected` tags return `_checked`. They therefore go directly into the `input` element, without an attribute name before them. As area tags, they apply when the respective option is selected. This lets you show and hide the matching password field, as in the example.

> [!WARNING]
>
> All 18 tags of this family apply exclusively in the `LoginUser` area of the login template.

## Registration after a guest order

If a buyer has ordered without an account, you can offer them immediately afterwards to create an account from the data they entered.

| Tag | Returns |
| - | - |
| `WS-CreateAccountAfterGuestOrder_pw` | the entered password |
| `WS-CreateAccountAfterGuestOrder_pw_input` | the HTML name of the password field |
| `WS-CreateAccountAfterGuestOrder_pw_error` | the error style suffix |
| `WS-CreateAccountAfterGuestOrder_pwagain` | the repetition |
| `WS-CreateAccountAfterGuestOrder_pwagain_input` | its HTML name |
| `WS-CreateAccountAfterGuestOrder_pwagain_error` | its error style suffix |
| `WS-CreateAccountAfterGuestOrder_cancellink` | the link for canceling |

```html theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
{Type-CreateAccountAfterGuestOrder}
   {ST-CreateAccountAfterGuestOrder_method(websale)}
      <input type="password"
             name="~WS-CreateAccountAfterGuestOrder_pw_input~"
             class="eingabe~WS-CreateAccountAfterGuestOrder_pw_error~">
      <input type="password"
             name="~WS-CreateAccountAfterGuestOrder_pwagain_input~"
             class="eingabe~WS-CreateAccountAfterGuestOrder_pwagain_error~">

      <a href="~WS-CreateAccountAfterGuestOrder_cancellink~">Abbrechen</a>
      <input type="submit" name="~BT-CreateAccountAfterGuestOrder~" value="Konto anlegen">
   {/ST-CreateAccountAfterGuestOrder_method(websale)}
{/Type-CreateAccountAfterGuestOrder}
```

> [!NOTE]
>
> Only the password is still requested. Everything else, from the address to the email address, the buyer has already entered when ordering.

> [!WARNING]
>
> Offer the cancellation visibly. Without `WS-CreateAccountAfterGuestOrder_cancellink`, the buyer has no way out of the registration, and they have only just placed an order.

> [!NOTE]
>
> The tags apply on the login page and on the order receipt confirmation. The cancel link applies only on the login page.

## Login via an external account

If a buyer logs in via an external account, the shop system has to find out whether a customer account already belongs to it. For this, it requests the email address and, if an account exists, the associated password as well.

| Tag | Returns |
| - | - |
| `WS-ExternLogin_facebook_connect_email` | the entered email address |
| `WS-ExternLogin_facebook_connect_email_input` | its HTML name |
| `WS-ExternLogin_facebook_connect_email_error` | its error style suffix |
| `WS-ExternLogin_facebook_Connect_pw_input` | the HTML name of the password field |
| `WS-ExternLogin_facebook_Connect_pw_error` | its error style suffix |
| `WS-ExternLogin_facebook_Connect_pw_needed` | applies when a password is needed |

```html theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
{Type-ExternLoginConnectAccounts}
   {ST-ExternLogin_facebook_connect}
      <form action="~FORM-ExternLogin_facebook_connect~" method="post" autocomplete="off">
         <input type="text"
                name="~WS-ExternLogin_facebook_connect_email_input~"
                value="~WS-ExternLogin_facebook_connect_email~"
                class="eingabe~WS-ExternLogin_facebook_connect_email_error~">

         {WS-ExternLogin_facebook_Connect_pw_needed}
            <p>Zu dieser Adresse gibt es bereits ein Konto. Bitte bestätigen Sie es.</p>
            <input type="password"
                   name="~WS-ExternLogin_facebook_Connect_pw_input~"
                   maxlength="64"
                   class="eingabe~WS-ExternLogin_facebook_Connect_pw_error~">
         {/WS-ExternLogin_facebook_Connect_pw_needed}

         <input type="submit" value="Verbinden">
      </form>
   {/ST-ExternLogin_facebook_connect}
{/Type-ExternLoginConnectAccounts}
```

> [!WARNING]
>
> Put the password field in `{WS-ExternLogin_facebook_Connect_pw_needed}`. If there is no account for the address yet, no password is needed, and a field displayed anyway only causes confusion.

> [!NOTE]
>
> Pay attention to upper and lower case: in the email branch it is `connect_email`, in the password branch `Connect_pw` with a capital C. This is how it is stored in the shop system.

## Confirming the email address

| Tag | Returns |
| - | - |
| `WS-DoubleOptInLink` | the activation link for the mandatory confirmation |
| `WS-VoluntaryDoubleOptInVerificationLink` | the link for the voluntary confirmation |
| `WS-RequestVoluntaryDoubleOptInEmailLink` | the link with which the buyer requests this email |
| `WS-RequestDeleteAccountDoubleOptInEmailLink` | the link with which they request the email for deleting their account |
| `WS-EmailVerified` | applies when the address is confirmed |

**In the email template** is the link that confirms the address:

```html theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<p>
   Bitte bestätigen Sie Ihre E-Mail-Adresse:
   <a href="~WS-DoubleOptInLink~">Adresse bestätigen</a>
</p>
```

**In the shop** is the notice about the still pending status:

```html theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
{ST-LoggedIn}
   {!WS-EmailVerified}
      <p>
         Ihre E-Mail-Adresse ist noch nicht bestätigt.
         <a href="~WS-RequestVoluntaryDoubleOptInEmailLink~">E-Mail erneut anfordern</a>
      </p>
   {/!WS-EmailVerified}
{/ST-LoggedIn}
```

> [!WARNING]
>
> `WS-EmailVerified` is only meaningful in the logged-in state. Put it in `{ST-LoggedIn}`, otherwise the negative area tag also applies to every visitor who is not logged in, and they get a notice about an account they do not even have.

> [!NOTE]
>
> `WS-DoubleOptInLink` and `WS-VoluntaryDoubleOptInVerificationLink` belong in the email templates defined in the sections `NewCustomerDoubleOptInMail`, `ChangeEmailDoubleOptInMail` and `CustomerVoluntaryDoubleOptInMail` of the shop configuration. The two request links belong in the shop.

> [!WARNING]
>
> `WS-RequestDeleteAccountDoubleOptInEmailLink` does not trigger a deletion, only the sending of the email. The deletion only happens when the buyer clicks the link in this email. Word the text in the template accordingly so that no one gets the wrong impression.

### The registration code

```html theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
{WS-LoginRegistrationCode}
   <p>Registrierungscode: ~WS-LoginRegistrationCode~</p>
{/WS-LoginRegistrationCode}
```

> [!NOTE]
>
> If the shop works with a registration code for new customers, `WS-LoginRegistrationCode` outputs the code and, as an area tag, checks whether one is present. `WS-LoginRegistrationCode_error` returns the error style suffix. Both tags exist in the shop system but are not described in the previous documentation.

> [!NOTE]
>
> If no one is logged in and no code is stored in the account, the tag falls back on the value stored in the shop configuration.

## The customer account

| Tag | Returns |
| - | - |
| `WS-LastLoginDate` | the date of the last login |
| `WS-LastLoginTime` | the associated time |
| `WS-UserCredit` | the balance of the customer account |
| `WS-OrderCount()` | the number of orders |
| `WS-SubAccountID` | the ID of the sub-account for multiple accounts |

```html theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
{WS-LastLoginDate}
   <p>Ihr letzter Besuch war am ~WS-LastLoginDate~ um ~WS-LastLoginTime~ Uhr.</p>
{/WS-LastLoginDate}
```

> [!WARNING]
>
> After a new registration, `WS-LastLoginDate` and `WS-LastLoginTime` return nothing on the **first** visit, because there is no earlier login yet. The value only appears from the second login onward. Without the area tag, the first visit would show a sentence with an empty gap on the page.

### The number of orders

```html theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
~WS-OrderCount~             <!-- alle Bestellungen im aktiven Subshop -->
~WS-OrderCount(1y,single)~  <!-- des letzten Jahres, aktiver Subshop -->
~WS-OrderCount(6m,all)~     <!-- der letzten 6 Monate, alle verbundenen Subshops -->
```

| No. | Meaning | Values |
| - | - | - |
| 1 | Period | number plus `d` for days, `m` for months or `y` for years |
| 2 | Scope | `single` for the active subshop, `all` for all connected ones, default `single` |

> [!NOTE]
>
> Without a parameter, the tag counts all orders in the active subshop. The area tag applies if there are any orders at all, and takes the same period into account.

> [!NOTE]
>
> The count is the fastest way to distinguish first-time buyers from regular customers without loading the order history. `{!WS-OrderCount(1y)}` applies to everyone who has not bought anything in the last year.

> [!NOTE]
>
> `WS-SubAccountID` exists in the shop system but is not described in the previous documentation. It outputs the ID of the sub-account and applies as an area tag when one is present. In a shop without multiple accounts, it stays silent.

## Links into the customer account

| Tag | Leads to |
| - | - |
| `WS-LoginLink` | the login page |
| `WS-LogoutLink` | logout |
| `WS-UserAccountLink` | the customer account overview |
| `WS-AddrManageLink` | the management of address data |
| `WS-BankManageLink` | the management of bank details |
| `WS-AutoLoginManageLink` | the management of saved logins |
| `WS-PrimePackagesManage` | the management of Prime packages |
| `WS-UserDownloadLink` | the buyer's download area |
| `WS-SavedBasketsManageLink` | the management of saved baskets |
| `WS-PPCVaultManageLink` | the management of stored PayPal payment methods |

```html theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
{ST-LoggedIn}
   <a href="~WS-UserAccountLink~">Mein Konto</a>
   <a href="~WS-AddrManageLink~">Adressen</a>
   <a href="~WS-UserDownloadLink~">Meine Downloads</a>
   <a href="~WS-LogoutLink~">Abmelden</a>
{/ST-LoggedIn}

{!ST-LoggedIn}
   <a href="~WS-LoginLink~">Anmelden</a>
{/!ST-LoggedIn}
```

> [!WARNING]
>
> The example on the previous page for `WS-UserDownloadLink` writes `<a href="~WS-UserDownloadLink~>` without a closing quotation mark. This breaks the element in the browser. The corrected version is shown above.

> [!NOTE]
>
> Most of these links only make sense for a logged-in buyer. Put them in `{ST-LoggedIn}` instead of relying on the shop system sending a visitor who is not logged in to the login page anyway.

> [!NOTE]
>
> Three of these tags come with their own check and also work as area tags. `WS-BankManageLink` only applies if saving bank details is enabled. `WS-SavedBasketsManageLink` only applies when the buyer is logged in. `WS-PPCVaultManageLink` only applies if storing PayPal payment methods is allowed.

```html theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
{WS-BankManageLink}
   <a href="~WS-BankManageLink~">Ihre gespeicherten Bankverbindungen</a>
{/WS-BankManageLink}
```

> [!NOTE]
>
> `WS-SavedBasketsManageLink` and `WS-PPCVaultManageLink` exist in the shop system but are not described in the previous documentation. Both generate a complete address via HTTPS.

> [!NOTE]
>
> `WS-OSBLink` is the odd one out: it does not lead into the customer account but into the shop operator's online service area, and it belongs in the order receipt email to the shop operator. The address comes from the shop configuration.

## The SuperUser customer search

```html theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
<form action="~FORM-UserSearch~" method="post">
   <input type="text" name="~WS-UserSearch_Input~" value="~WS-UserSearch~">
   <select name="user_search_type">
      <option value="Name">Name</option>
      <option value="Email">E-Mail-Adresse</option>
      <option value="Number">Kundennummer</option>
   </select>
   <input type="submit" value="Suchen">
</form>

{CAT-AdvData($UserSearch,999)}
   <p>Die Suche ergab ~WS-UserSearchResults~ Treffer.</p>
   ...
{/CAT-AdvData($UserSearch,999)}
```

| Tag | Returns |
| - | - |
| `WS-UserSearch_Input` | the HTML name of the search field |
| `WS-UserSearch` | the previous input |
| `WS-UserSearchType` | the selected search type |
| `WS-UserSearchResults` | the number of hits |
| `WS-SuperUserID` | the ID of the logged-in SuperUser |

> [!WARNING]
>
> The selection list for the search type has the **fixed** name `user_search_type`. There is no dedicated tag for it. `WS-UserSearchType` only returns the selected value so that a JavaScript can mark the correct option again.

> [!WARNING]
>
> The page title of the previous documentation writes the tag as `WS-SuperUser-ID` with an additional hyphen. In the shop system and in the source's own examples it is called `WS-SuperUserID`. Only this spelling works.

Reference: You build the hit list itself with the `UL-` tags, described on UL- (SuperUser)

## The tags at a glance

| Tag | Single tag | Area tag | Negative area tag | Loop tag |
| - | - | - | - | - |
| `WS-UserID`, `WS-Email`, `WS-NewEmail`, `WS-EmailAgain` | yes | – | – | – |
| `WS-PW`, `WS-NewPW`, `WS-PWAgain` | yes | – | – | – |
| all associated `_input` tags | yes | – | – | – |
| all associated `_error` tags | yes | yes | yes | – |
| `WS-PWRequestZip` | yes | – | – | – |
| `WS-RequestPWLink` | yes | – | – | – |
| `WS-SecureLoginConfigurationJS` | yes | – | – | – |
| `WS-StaySignedIn_input` | yes | – | – | – |
| `WS-StayFullySignedIn_input` | yes | – | – | – |
| `WS-UserRequiresReAuthForCritAction` | – | yes | yes | – |
| `WS-CombinedLogin_radioname` | yes | – | – | – |
| `WS-CombinedLogin_radiovalue_*` | yes | – | – | – |
| `WS-CombinedLogin_radioselected_*` | yes | yes | yes | – |
| `WS-CombinedLogin_eMail` and the three password fields | yes | yes | yes | – |
| `WS-CombinedLogin_*_input` | yes | – | – | – |
| `WS-CombinedLogin_*_error` | yes | yes | yes | – |
| `WS-CreateAccountAfterGuestOrder_pw` and `_pwagain` | yes | yes | yes | – |
| `WS-CreateAccountAfterGuestOrder_*_input` | yes | – | – | – |
| `WS-CreateAccountAfterGuestOrder_*_error` | yes | yes | yes | – |
| `WS-CreateAccountAfterGuestOrder_cancellink` | yes | – | – | – |
| `WS-ExternLogin_facebook_connect_email` | yes | yes | yes | – |
| `WS-ExternLogin_facebook_connect_email_input` | yes | – | – | – |
| `WS-ExternLogin_facebook_connect_email_error` | yes | yes | yes | – |
| `WS-ExternLogin_facebook_Connect_pw_input` | yes | – | – | – |
| `WS-ExternLogin_facebook_Connect_pw_error` | yes | yes | yes | – |
| `WS-ExternLogin_facebook_Connect_pw_needed` | – | yes | yes | – |
| `WS-DoubleOptInLink` | yes | yes | yes | – |
| `WS-VoluntaryDoubleOptInVerificationLink` | yes | yes | yes | – |
| `WS-RequestVoluntaryDoubleOptInEmailLink` | yes | yes | yes | – |
| `WS-RequestDeleteAccountDoubleOptInEmailLink` | yes | – | – | – |
| `WS-EmailVerified` | – | yes | yes | – |
| `WS-LoginRegistrationCode` | yes | yes | yes | – |
| `WS-LoginRegistrationCode_error` | yes | yes | yes | – |
| `WS-LastLoginDate`, `WS-LastLoginTime` | yes | yes | yes | – |
| `WS-UserCredit` | yes | – | – | – |
| `WS-OrderCount()` | yes | yes | yes | – |
| `WS-SubAccountID` | yes | yes | yes | – |
| `WS-LoginLink`, `WS-LogoutLink`, `WS-UserAccountLink` | yes | – | – | – |
| `WS-AddrManageLink`, `WS-AutoLoginManageLink`, `WS-UserDownloadLink` | yes | – | – | – |
| `WS-OSBLink` | yes | – | – | – |
| `WS-BankManageLink` | yes | yes | yes | – |
| `WS-PrimePackagesManage` | yes | yes | yes | – |
| `WS-SavedBasketsManageLink` | yes | yes | yes | – |
| `WS-PPCVaultManageLink` | yes | yes | yes | – |
| `WS-UserSearch`, `WS-UserSearch_Input`, `WS-UserSearchType`, `WS-UserSearchResults` | yes | – | – | – |
| `WS-SuperUserID` | yes | yes | yes | – |
| `WS-AppLoginErrorCode` | yes | yes | yes | – |

The login and registration fields apply on the login template, the `CombinedLogin` family there in the `LoginUser` area. `WS-BankManageLink` and `WS-PrimePackagesManage` apply on the customer account overview, `WS-DoubleOptInLink` and `WS-VoluntaryDoubleOptInVerificationLink` in the associated email templates, `WS-OSBLink` in the order receipt email to the shop operator, and the customer search tags on their template. All others are permitted on all templates.

## Related topics

* Guide: Login and registration
* Guide: Persistent login
* Guide: Double opt-in
* Guide: Forgotten password
* Guide: SuperUser function
* Reference: UL- (SuperUser)


## Related topics

- [Customer, login, and customer account](https://dokumentation.websale.de/en/v8s/referenz/konfigurationen/shopkonfiguration-shop-config/kunde-anmeldung-und-kundenkonto.md)
- [MSG- (Messages)](https://dokumentation.websale.de/en/v8s/referenz/tags/msg-meldungen.md)
- [Buttons for customer account and login](https://dokumentation.websale.de/en/v8s/referenz/tags/bt/kundenkonto-und-anmeldung.md)
- [DA- (Deleting the customer account)](https://dokumentation.websale.de/en/v8s/referenz/tags/da-kundenkonto-loeschen.md)
- [Storefront API Customer Account](https://dokumentation.websale.de/en/schnittstellen/storefront-api/storefront-api-kundenkonto.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.