Email and password custom rules

To override the default validation rules for the email and password fields, we have custom rules that can be passed in. These are nested within the emailPassword object at the top level of the configuration file.

These settings take in a type of layeredValidation that accepts a format and a translationKey that must be one of the custom1 to custom10 that is thrown when the validation fails.

Email

Configuration option key: email

Available Options

`format`	Defines a regex that the email address must match
`translationKey`	This is the translation key that is shown when the custom validation fails. This must be a value of `custom1` to `custom10` and then defined in the translation file.

  "emailPassword": {
    "email": {
      "layeredValidation": [
        {
          "format": "apple|google|microsoft",
          "translationKey": "custom2"
        }
      ]
    },
  },

In the above example, the email address can not contain any email addresses that contain either apple, google or microsoft. If they do, the frontend validation will fail with an error message using the translation key: custom2.

Password

Configuration option key: password

Available Options

`format`	Defines a regex that the password must match
`translationKey`	This is the translation key that is shown when the custom validation fails. This must be a value of `custom1` to `custom10` and then defined in the translation file.

  "emailPassword": {
    "password": {
      "minLength": 12,
      "layeredValidation": [
        {
          "format": "[A-Z].*[A-Z]",
          "translationKey": "custom1"
        }
      ]
    }
  },

In the above example, the password must contain a format that matches the provided regex. If it does not, the frontend validation will fail and display the value of the custom1 translation key.

Password Service

Implement a custom password validation service

The external password validation is designed for use during the migration phase to SCAYLE, offering a convenient method to transfer customer passwords without direct access. This process involves outsourcing the password validation to a separate system that determines its validity. After successful verification, the password can be securely rehashed and stored. This ensures that only one successful attempt per customer is needed for a seamless password migration.

SCAYLE will activate this feature if requested.
Customers need to be flagged as "having external password" in order to trigger the described flow
Please contact your SCAYLE Account Manager for further information.

How to implement

You are required to establish an HTTP service capable of handling your shop's standard traffic load, while also accepting requests from the SCAYLE networks.

To restrict incoming traffic by IP address, kindly consult your SCAYLE Account Manager for detailed information about our networks.

This service needs to implement a POST endpoint according to the following schema:

Endpoint

POST {{baseUrl}}/checkout/password/credentials

Authentication

Basic auth. The credentials for this service need to be provided to your SCAYLE Account Manager.

Body

Request example

{
  "password": "test123",
  "hash": "$2y$12*********************f0Xvza21oAqJabkyseL12Bd/gi",
  "email": "[email protected]"
}

Request schema

password string
hash string (optional - shows which hash would be used internally, can be ignored)
email string

Response

Your service needs to follow this specification when handling the checkout request.

Status Codes:

Your service should return a 200 status code to signal to the checkout process that the submitted credentials are valid, can be migrated, and do not require further external validation.

Code	Description	Response Body
`200`	credentials are valid	empty
`401`	authentication failed	empty
`406`	invalid data	empty