less than a minute read • Updated 5 minutes ago
Sync Users Between Foxy and an External System
Because Foxy was built from the ground up to augment and not replace external systems, it is a common occurrence that Foxy customer records will need to be created or updated from an external system, or that Foxy customers will need to automatically create users in external systems (like a CMS or CRM). Typically an integration like this will primarily use the JSON webhook and the API to create and sync users, and Single Sign-On (SSO) to make the customer checkout experience seamless.
Customer Passwords
While the possibilities for this type of synchronization are near limitless, the single most important thing is usually the customer's password. Foxy customer passwords are returned by the JSON webhook and the API as hashes, and not the actual cleartext password. While the initial user creation is generally straightforward it can get tricky to maintain sync when passwords are reset, so if you tackle an advanced integration you must ensure that any and all password resetting functionality on your systems simultaneously updates the Foxy customer record through the API.
Password hashes are represented in the API and JSON webhook as hexadecimal strings, for example “2e29f4fa2efb67dc28860abf”. Depending on your library's hash functions, you may need to convert the output of the hash function to a hexadecimal string in order to compare passwords. Any “salt” value generated by Foxy is a random string of letters and numbers.
Hashing Methods
Foxy currently supports the following hashing methods (in alphabetical order, and in PHP pseudocode, using $ to denote a variable, . to denote concatenation, and a single quote to encapsulate a string):
Argon2id | Method: Notes: It will use the default configuration options when generating the hash |
BCrypt (with cost) | Method: Configuration: The cost, default 14 Notes: This is the recommended hashing method. It will generate the standard Supported Systems:
|
BCrypt (for WordPress 6.8+) | Method: Configuration: The cost, default 10 Notes: It will generate the Wordpress specific Supported Systems:
|
concrete5 | Method: Configuration: The configuration value is the one single salt used for all customer records, since Concrete5 uses a single site-wide salt. |
Craft CMS | Method: Specific to Craft. |
ExpressionEngine | Method: Specific to ExpressionEngine. |
joomla | Method: Configuration: The length of the randomly generated salt. Notes: This is the method used as of Joomla 1.0.13. |
kohana3 | Method: The hashing methods in the Kohana3 Auth module. Configuration: The Auth module's |
Magento MD5 | Method: For older Magento installations. |
md5 | Method: Configuration: n/a Notes: This is provided for legacy purposes, as many older systems may use unsalted MD5 hashes. It is not recommended unless you need to sync with a system that requires it. |
md5_salted_suffix | Method: Configuration: The length of the randomly generated salt. |
md5_salted_suffix_2char | Method: Configuration: n/a Notes: This really should only be used for synching to osCommerce prior to v2.3. |
pbkdf2 | Method: Microsoft Identity v2 PBKDF2 implementation Configuration: Comma separated values for Notes: Returns a base64 encoded string, made up of a concatenated string using |
pbkdf2 | Method: From MODX Revolution's code. Note that MODX no longer uses this method. Configuration: Comma separated values for Notes: Returns a base64 encoded hash, and uses a 32 character long salt Supported Systems:
|
phpass | Method: Uses the phpass library in “portable” mode. (Portable mode is what most systems that use phpass default to.) Configuration: The configuration value sets the iterations used to instantiate the Supported Systems:
|
sha1 | Method: Configuration: n/a Notes: This is provided for legacy purposes, as many older systems may use unsalted MD5 hashes. It is not recommended unless you need to sync with a system that requires it. |
sha1_salted_suffix | Method: Configuration: The length of the randomly generated salt. Supported Systems:
|
sha256_salted_suffix | Method: Configuration: The length of the randomly generated salt. |
sha256_salted_prefix | Method: Configuration: The length of the randomly generated salt. |
drupal sha512 | Method: Configuration: The iterations the password is stretched by. Supported Systems:
Notes: Beginning in v10.1.0, Drupal uses PHP's standard |
Webvanta SHA1 | Method: Specific to Webvanta. |
If you need alternate hashing methods, please let us know.
Once the user creation and synchronization functionality is handled, Single Sign-On (SSO) allows a customer who's already logged into the merchant's site to continue through to checkout with their user already loaded. This prevents users from needing to log in once to a site, then again on checkout. (SSO checkouts require the CSC to be entered, in order to minimize the risk of a malicious user stealing a cookie and processing an order using saved payment information.)
Changing Hashing Methods
The customers hashing method is stored against their user record (which you can in turn access via the JSON webhook and the API as well), and that is the hashing method used to validate their password when they login. If you've changed the hashing method from one to another, any existing customers will be validated against their old hashing method on login, and then once they complete a checkout for your store their password will be rehashed with the new hashing method selected in your stores settings.