Generowanie ciągów uwierzytelniających (REST API)

Ostatnia aktualizacja: 7 października 2026

Niektóre punkty końcowe REST umożliwiają wykonywanie wrażliwych operacji, takich jak składanie zleceń lub żądanie wypłaty aktywów cyfrowych. Prywatne punkty końcowe można wywoływać wyłącznie za pomocą zaszyfrowanych żądań – każde z nich musi zawierać ciąg uwierzytelniający (authent). authent jest obliczany na podstawie następujących danych wejściowych:

PostData

postData is a "&" concatenation in the form <argument>=<value> and is specific to each REST endpoint.

Przykład

Aby obsługiwać punkt końcowy orderbook, wybierz argument symbol z wartością
fi_xbtusd_180615. postData przyjmuje wówczas wartość symbol=fi_xbtusd_180615.

Aktualizacja procesu uwierzytelniania dla punktów końcowych v3: od 20 lutego 2024 r., w celu dostosowania do najlepszych praktyk i zapewnienia wyższego poziomu bezpieczeństwa, zaktualizujemy proces uwierzytelniania dla punktów końcowych /derivatives/* (v3). (szczegóły poniżej)

Zmiany w generowaniu PostData:


- Przed wydaniem: klienci musieli hashować parametry ciągu zapytania przed kodowaniem URL na potrzeby generowania Authent, np. `greeting=hello world`.


- Po wydaniu: proces uwierzytelniania będzie wymagał hashowania pełnego, zakodowanego w URL komponentu URI dokładnie tak, jak pojawia się w żądaniu, np. `greeting=hello%20world`. Ta metoda zwiększa bezpieczeństwo i jest zgodna z najlepszymi praktykami.
Ta aktualizacja jest szczególnie istotna dla punktu końcowego v3 batchorder, który przyjmuje treść JSON w parametrach zapytania.


Kompatybilność wsteczna i plany na przyszłość:


Zmiana ta jest obecnie kompatybilna wstecznie. Platforma akceptuje obie opisane powyżej metody generowania PostData. Planujemy jednak wycofać starą metodę (hashowanie zdekodowanych parametrów ciągu zapytania), aby utrzymać najwyższe standardy bezpieczeństwa. Z wyprzedzeniem poinformujemy o tej zmianie i zdecydowanie zachęcamy wszystkich klientów do jak najszybszego przejścia na nową metodę w celu zapewnienia ciągłości działania usługi.

Nonce

nonce to stale rosnący parametr całkowitoliczbowy. Dobrą wartością nonce jest czas systemowy w
milisekundach (w formacie ciągu znaków). System toleruje wartości nonce przekazywane poza kolejnością przez krótki czas. Nonce nie jest wymagany.

Przykład 1415957147987

Wiele problemów z uwierzytelnianiem wynika z nieprawidłowej wartości nonce. Wygenerowanie nowej pary kluczy API automatycznie resetuje nonce i rozwiązuje te problemy.

Ścieżka punktu końcowego

endpointPath to rozszerzenie URL punktu końcowego.

Przykład /api/v3/orderbook

API Secret

api_secret uzyskuje się zgodnie z opisem w poprzedniej sekcji.

Przykład

rttp4AzwRfYEdQ7R7X8Z/04Y4TZPa97pqCypi3xXxAqftygftnI6H9yGV+O
cUOOJeFtZkr8mVwbAndU3Kz4Q+eG

Na podstawie tych danych wejściowych wartość authent należy obliczyć w następujący sposób:

  1. 1

    Połącz

    postData

    +

    nonce

    +

    endpointPath

  2. 2

    Oblicz hash wyniku kroku 1 przy użyciu algorytmu SHA-256

  3. 3

    Zdekoduj metodą Base64 swój api_secret

  4. 4

    Użyj wyniku kroku 3, aby zahashować wynik kroku 2 za pomocą algorytmu HMAC-SHA-512

  5. 5

    Zakoduj w Base64 wynik kroku 4

Przykład

Poniżej przedstawiono implementację authent w języku Java. Pełne przykłady działającego kodu w różnych językach programowania znajdziesz w sekcji Dodatkowe zasoby. 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();
}