Come risolvere il 401 Access Denied di user/syncrequest sul WebSocket di Tradovate

Avete aperto un WebSocket, lanciato user/syncrequest, e invece di un flusso di dati su conto e ordini avete ricevuto un secco 401 con “Access is denied.” Non c'è nulla che non va nel vostro login e nulla è rotto nel conto. Il socket semplicemente non è mai stato autorizzato, quindi il server tratta ogni richiesta su di esso come anonima. La soluzione è un ordine specifico di operazioni: prendete un token di accesso dall'endpoint di autenticazione REST, consegnatelo al socket in un frame authorize, attendete la risposta di successo, e solo allora inviate user/syncrequest. Rispettate questa sequenza e il 401 sparisce.

Questo inganna quasi tutti la prima volta che collegano il socket di Tradovate a mano, di solito perché cercano di autenticarsi come funziona REST. I WebSocket non funzionano così qui. Ripercorriamo esattamente cosa succede e la via pulita per uscirne.

Come si presenta davvero l'errore

Nel vostro log dei frame vedrete il socket connettersi, arrivare il frame open, poi il vostro user/syncrequest tornare immediatamente con un rifiuto. Si presenta più o meno così:

<-- o
--> user/syncrequest
1

<-- a[{"i":1,"s":401,"d":"Access is denied"}]

L'indizio rivelatore è lo stato 401 abbinato a Access is denied sul frame di richiesta. Se non avete mai visto una risposta di stato 200 a un frame authorize prima di questo, ecco la vostra risposta: il socket non è autenticato.

Perché il socket restituisce un 401

In realtà ci sono solo una manciata di cause radice, e si accumulano in un ordine prevedibile.

1. Il socket non è mai stato autorizzato

Questa è la causa principale. Una connessione WebSocket grezza a Tradovate non è autenticata. Aprirla e inviare immediatamente user/syncrequest equivale a entrare in un club per soci e ordinare da bere senza mostrare la tessera. Dovete inviare esattamente un frame authorize per connessione, contenente un token di accesso valido, prima che qualsiasi altra cosa possa passare.

2. Avete provato a ottenere il token tramite il socket

Un errore comune è tentare di chiamare accessTokenRequest tramite il WebSocket stesso. Quell'endpoint vive sul lato REST. Il token viene coniato via HTTPS, e poi presentato al socket. Il socket non emette mai token.

3. Un parametro environment nella richiesta del token

Se avete copiato un corpo di richiesta da qualche parte e include "environment": "demo" (o "live"), rimuovetelo. Quel campo non è accettato da accessTokenRequest e può mandare fuori strada l'intera richiesta. L'ambiente è deciso dall'host che chiamate, non da un parametro.

4. Un conto reale senza deviceId o con un dispositivo non approvato

Il demo è permissivo. Il reale no. Su un conto finanziato/reale dovete inviare un deviceId stabile quando richiedete il token, e il dispositivo deve essere approvato tramite il flusso di conferma che Tradovate esegue per la sicurezza a due fattori. Se saltate questo passaggio, il token reale che ottenete non autorizzerà il socket reale.

5. Il token è scaduto

Se prima tutto funzionava e poi ha iniziato a restituire 401 dal nulla, il token è scaduto. I token di accesso sono limitati nel tempo, quindi un socket di lunga durata alla fine vedrà un 401 come se non fosse mai stato autorizzato. Questo è un problema di rinnovo, non di configurazione.

La soluzione, passo dopo passo

Conti reali: il controllo di deviceId e permessi

Se il demo funziona perfettamente e il reale è l'unico posto in cui incontrate il 401, la causa è quasi sempre sul lato dell'approvazione del dispositivo piuttosto che nel vostro codice. Due cose da confermare.

Primo, assicuratevi che l'accesso API sia effettivamente abilitato sul conto e che la chiave abbia il permesso di fare ciò che state chiedendo. Nella web app di Tradovate questo si trova nelle impostazioni account, nella sezione che gestisce il componente aggiuntivo API Access e i permessi della chiave. (Confermate l'etichetta esatta nella vostra versione attuale, il testo e la posizione di questa schermata del componente aggiuntivo vengono modificati nel tempo.)

Secondo, inviate un deviceId che resti lo stesso tra le esecuzioni e approvatelo. Il reale impone una sicurezza a due fattori basata sul dispositivo; un deviceId nuovo di zecca o mancante attiva un passaggio di approvazione che, finché non lo risolvete, lascia il token incapace di autorizzare il socket reale. Generate un identificatore stabile per la vostra app, riutilizzatelo ogni volta, e confermatelo tramite l'email che invia Tradovate.

Continuate a ricevere 401? Seguite questa checklist

Se funzionava e poi si è rotto a metà sessione, andate direttamente alla durata del token. I token di accesso non durano per sempre, e un socket rimasto aperto per un po' inizierà a restituire 401 nel momento in cui il token sottostante scade. Rinnovate prima della scadenza invece di aspettare gli errori. E se è la primissima richiesta di token a fallire, tornate indietro per verificare l'accesso API e la generazione di una chiave prima di toccare affatto il socket.

Saltate del tutto l'idraulica del socket

Costruire a mano l'handshake di autenticazione, gli heartbeat, l'approvazione del dispositivo e il rinnovo del token sono un sacco di parti mobili solo per instradare un ordine. Se state collegando Tradovate ad alert di TradingView o a una strategia, PickMyTrade gestisce per voi l'intero livello di connessione, sessioni autorizzate, gestione dei dispositivi reali e rinnovo dei token inclusi, così voi inviate un segnale e viene eseguito il trade.