Certains points de terminaison REST permettent d'effectuer des opérations sensibles telles que le placement d'ordres ou la demande de retrait d'actifs numériques. Ces points de terminaison privés ne peuvent donc être appelés que via des requêtes chiffrées et une chaîne d'authentification (authent) doit être incluse dans chaque requête de ce type. L'authentification est calculée à partir des entrées suivantes :
postData est une concaténation "&" sous la forme <argument>=<value> et est spécifique à chaque point de terminaison REST.
Exemple | Pour utiliser le carnet d'ordres du point de terminaison, vous choisissez l'argument symbole avec la valeur |
|---|
Mise à jour du flux d'authentification pour les points de terminaison v3 : À compter du 20 février 2024, afin de s'aligner sur les meilleures pratiques et d'assurer un niveau de sécurité plus élevé, nous allons mettre à jour le flux d'authentification pour nos points de terminaison /derivatives/* (v3). (détails ci-dessous)
Modifications de la génération de PostData :
- Avant la publication : Les utilisateurs devaient hacher les paramètres de la chaîne de requête avant l'encodage URL pour la génération d'Authent, par exemple, `greeting=hello world`.
- Après la publication : Le processus d'authentification exigera désormais le hachage du composant URI complet, encodé en URL, tel qu'il apparaît dans la requête, par exemple, `greeting=hello%20world`. Cette méthode renforce la sécurité et s'aligne sur les meilleures pratiques.
Cette mise à jour est particulièrement pertinente pour le point de terminaison v3 batchorder, qui accepte un corps JSON dans ses paramètres de requête.
Rétrocompatibilité et plans futurs :
Pour l'instant, ce changement est rétrocompatible. La plateforme acceptera les deux méthodes de génération de PostData décrites ci-dessus. Cependant, nous visons à supprimer progressivement l'ancienne méthode (hachage des paramètres de chaîne de requête décodés) à l'avenir afin de maintenir les normes de sécurité les plus élevées. Nous fournirons un préavis suffisant avant ce changement et encourageons fortement tous les utilisateurs à passer à la nouvelle méthode dès que possible pour assurer une continuité de service sans faille.
nonce est un paramètre entier à incrémentation continue. Un bon nonce est l'heure de votre système en
millisecondes (au format chaîne). Notre système tolère les nonces qui sont désordonnés pendant une courte période. Le nonce n'est pas obligatoire.
Exemple 1415957147987 |
|---|
De nombreux problèmes d'authentification sont liés à un nonce incorrect. Une nouvelle paire de clés API réinitialisera automatiquement le nonce et résoudra ces problèmes.
endpointPath Il s'agit de l'extension d'URL du point de terminaison.
Exemple /api/v3/orderbook |
|---|
L'api_secret est obtenu comme décrit dans la section précédente.
Exemple | rttp4AzwRfYEdQ7R7X8Z/04Y4TZPa97pqCypi3xXxAqftygftnI6H9yGV+O |
|---|
Sur la base de ces entrées, l'authentification doit être calculée comme suit :
Concaténer
postData
+
nonce
+
endpointPath
Hacher le résultat de l'étape 1 avec l'algorithme SHA-256
Décoder en Base64 votre api_secret
Utiliser le résultat de l'étape 3 pour hacher le résultat de l'étape 2 avec l'algorithme HMAC-SHA-512
Encoder en Base64 le résultat de l'étape 4
Exemple | ||
|---|---|---|
Ce qui suit montre une implémentation de l'authentification en Java. Pour des exemples complets et fonctionnels dans différents langages de programmation, consultez la section Ressources supplémentaires. public static String getAuthent(String postData, String nonce, String endpointPath, String secretKeyBase64) |