All
Filtruj według:
Jak mogę wpłacić gotówkę na konto?
Potrzebuję pomocy w weryfikacji konta
Dlaczego nie mogę uzyskać dostępu do konta?
Czy są jakieś opłaty za wypłatę kryptowalut?
Potrzebuję pomocy w zalogowaniu się na konto
Niektóre punkty końcowe REST umożliwiają wykonywanie wrażliwych operacji, takich jak składanie zleceń lub żądanie wypłaty aktywów cyfrowych. Te prywatne punkty końcowe mogą być zatem wywoływane tylko za pośrednictwem zaszyfrowanych żądań, a w każdym takim żądaniu musi być zawarty ciąg uwierzytelniający (authent). Ciąg uwierzytelniający jest obliczany na podstawie następujących danych wejściowych:
postData to konkatenacja "&" w formie <argument>=<value> i jest specyficzna dla każdego punktu końcowego REST.
Przykład | Aby obsłużyć punkt końcowy orderbook, wybierasz argument symbol o wartości |
|---|
Aktualizacja przepływu uwierzytelniania dla punktów końcowych v3: Od 20 lutego 2024 r., aby dostosować się do najlepszych praktyk i zapewnić wyższy standard bezpieczeństwa, aktualizujemy przepływ uwierzytelniania dla naszych punktów końcowych /derivatives/* (v3). (szczegóły poniżej)
Zmiany w generowaniu PostData:
- Przed wydaniem: Użytkownicy musieli haszować parametry ciągu zapytania przed kodowaniem URL dla generowania Authent, np. `greeting=hello world`.
- Po wydaniu: Proces uwierzytelniania będzie teraz wymagał haszowania pełnego, zakodowanego URL-em komponentu URI, 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 akceptuje ciało JSON w swoich parametrach zapytania.
Kompatybilność wsteczna i plany na przyszłość:
Na razie ta zmiana jest kompatybilna wstecz. Platforma będzie akceptować obie opisane powyżej metody generowania PostData. Jednakże, dążymy do wycofania starej metody (haszowania zdekodowanych parametrów ciągu zapytania) w przyszłości, aby utrzymać najwyższe standardy bezpieczeństwa. Zapewnimy odpowiednie wyprzedzenie przed tą zmianą i zdecydowanie zachęcamy wszystkich użytkowników do jak najszybszego przejścia na nową metodę, aby zapewnić ciągłość usług.
nonce to stale rosnący parametr całkowity. Dobrym nonce jest czas systemowy w
milisekundach (w formacie ciągu znaków). Nasz system toleruje nonce, które są poza kolejnością przez krótki okres czasu. Nonce nie jest wymagane.
Przykład 1415957147987 |
|---|
Wiele problemów z uwierzytelnianiem jest związanych z nieprawidłowym nonce. Nowa para kluczy API automatycznie zresetuje nonce i rozwiąże te problemy.
endpointPath To jest rozszerzenie URL punktu końcowego.
Przykład /api/v3/orderbook |
|---|
api_secret uzyskuje się zgodnie z opisem w poprzedniej sekcji.
Przykład | rttp4AzwRfYEdQ7R7X8Z/04Y4TZPa97pqCypi3xXxAqftygftnI6H9yGV+O |
|---|
Na podstawie tych danych wejściowych, authent należy obliczyć w następujący sposób:
Połącz
postData
+
nonce
+
endpointPath
Zahaszuj wynik kroku 1 za pomocą algorytmu SHA-256
Zdekoduj Base64 swój api_secret
Użyj wyniku kroku 3, aby zahaszować wynik kroku 2 za pomocą algorytmu HMAC-SHA-512
Zakoduj Base64 wynik kroku 4
Przykład | ||
|---|---|---|
Poniżej przedstawiono implementację authent w Javie. Pełne przykłady działania w różnych językach programowania można znaleźć w sekcji Dodatkowe zasoby. public static String getAuthent(String postData, String nonce, String endpointPath, String secretKeyBase64) |