Kimlik doğrulama dizeleri oluşturma (REST API)

Son güncelleme: 31 Mar 2025

Bazı REST uç noktaları, emir verme veya dijital varlık çekme talebinde bulunma gibi hassas işlemlerin gerçekleştirilmesine izin verir. Bu özel uç noktalar bu nedenle yalnızca şifreli istekler aracılığıyla çağrılabilir ve her böyle bir isteğe bir kimlik doğrulama dizesi (authent) dahil edilmelidir. authent aşağıdaki girdilerden hesaplanır:

PostData

postData, "&" biçiminde bir birleştirmedir: <argument>=<value> ve her REST uç noktasına özeldir.

Örnek

Uç nokta emir defterini çalıştırmak için fi_xbtusd_180615 değerine sahip sembol argümanını seçersiniz.
postData daha sonra symbol=fi_xbtusd_180615 olarak verilir.

v3 uç noktaları için Kimlik Doğrulama Akışı Güncellemesi: 20 Şubat 2024 itibarıyla, en iyi uygulamalarla uyumlu olmak ve daha yüksek bir güvenlik standardı sağlamak amacıyla, /derivatives/* (v3) uç noktalarımız için kimlik doğrulama akışını güncelleyeceğiz. (ayrıntılar aşağıda)

PostData Oluşturma Değişiklikleri:


- Sürümden önce: Kullanıcıların Authent oluşturma için URL kodlamadan önce sorgu dizesi parametrelerini hashlemesi gerekiyordu, örn., `greeting=hello world`.


- Sürümden sonra: Kimlik doğrulama süreci artık isteğinde göründüğü gibi tam, URL kodlu URI bileşeninin hashlenmesini gerektirecektir, örn., `greeting=hello%20world`. Bu yöntem güvenliği artırır ve en iyi uygulamalarla uyumludur.
Bu güncelleme, sorgu parametrelerinde bir JSON gövdesi kabul eden v3 batchorder uç noktası için özellikle önemlidir.


Geriye Dönük Uyumluluk ve Gelecek Planları:


Şimdilik, bu değişiklik geriye dönük olarak uyumludur. Platform, yukarıda açıklanan her iki PostData oluşturma yöntemini de kabul edecektir. Ancak, en yüksek güvenlik standartlarını korumak için eski yöntemi (çözülmüş sorgu dizesi parametrelerini hashleme) gelecekte aşamalı olarak kaldırmayı hedefliyoruz. Bu değişiklikten önce yeterli bildirimde bulunacağız ve tüm kullanıcıları kesintisiz hizmet sürekliliği sağlamak için mümkün olan en kısa sürede yeni yönteme geçmeye şiddetle teşvik ediyoruz.

Nonce

nonce, sürekli artan bir tam sayı parametresidir. İyi bir nonce, sistem saatinizin
milisaniye cinsinden (dize biçiminde) değeridir. Sistemimiz, kısa bir süre için sırasız noncelere tolerans gösterir. Nonce gerekli değildir.

Örnek 1415957147987

Birçok kimlik doğrulama sorunu yanlış nonce ile ilgilidir. Yeni bir API anahtarı çifti, nonce'u otomatik olarak sıfırlayacak ve bu sorunları çözecektir.

Uç Nokta Yolu

endpointPath Bu, uç noktanın URL uzantısıdır.

Örnek /api/v3/orderbook

API Gizli Anahtarı

api_secret, önceki bölümde açıklandığı gibi elde edilir.

Örnek

rttp4AzwRfYEdQ7R7X8Z/04Y4TZPa97pqCypi3xXxAqftygftnI6H9yGV+O
cUOOJeFtZkr8mVwbAndU3Kz4Q+eG

Bu girdilere dayanarak, kimlik doğrulama (authent) aşağıdaki gibi hesaplanmalıdır:

  1. 1

    Birleştirin

    postData

    +

    nonce

    +

    endpointPath

  2. 2

    1. adımın sonucunu SHA-256 algoritması ile hash'leyin

  3. 3

    api_secret'inizi Base64-çözün

  4. 4

    3. adımın sonucunu kullanarak 2. adımın sonucunu HMAC-SHA-512 algoritması ile hash'leyin

  5. 5

    4. adımın sonucunu Base64-kodlayın

Örnek

Aşağıda Java'da bir kimlik doğrulama (authent) uygulaması gösterilmektedir. Farklı programlama dillerindeki tam çalışma örnekleri için Ek Kaynaklar bölümüne bakın. public static String getAuthent(String postData, String nonce, String endpointPath, String secretKeyBase64)
{
Mac mac512;
MessageDigest sha256;
try {
SecretKey secretKey = new SecretKeySpec 
(Base64.decode(secretKeyBase64.getBytes()), HMAC_SHA_512);
mac512 = Mac.getInstance(HMAC_SHA_512);
mac512.init(secretKey);
sha256 = MessageDigest.getInstance("SHA-256");
} catch (IOException e) {
...
} catch (InvalidKeyException e) {
...
} catch (NoSuchAlgorithmException e) {
...
} sha256.update(postData.getBytes());
sha256.update(nonce.getBytes());
sha256.update(endpointPath.getBytes());
mac512.update(sha256.digest());
return Base64.encodeBytes(mac512.doFinal()).trim();
}

Daha fazla yardıma mı ihtiyacınız var?