Ripetizione WebSocket
Ripetizione WebSocket crea sessioni riutilizzabili per testare gli endpoint WebSocket. Usala per riconnetterti con i dettagli dell'handshake acquisito, modificare messaggi, inviare nuovi frame e osservare le risposte del server.
Creare una sessione
Puoi creare una sessione di Ripetizione WebSocket in due modi:
- Fai clic con il pulsante destro su un messaggio WebSocket acquisito in Cronologia WebSocket / SSE e scegli Invia a Ripetizione WS.
- Apri Ripetizione WS e crea manualmente una sessione con un URL
ws://owss://.
Le sessioni manuali possono includere intestazioni personalizzate per cookie, token di autorizzazione, negoziazione del protocollo o valori di handshake specifici dell'applicazione.
Configurare la sessione
| Campo | Descrizione |
|---|---|
| Nome | Etichetta leggibile della sessione. |
| URL | Endpoint WebSocket. L'URL deve iniziare con ws:// o wss://. |
| Intestazioni | Intestazioni facoltative dell'handshake inviate alla connessione. |
Se cambi l'URL o le intestazioni, Ogma salva la sessione prima di aprire la connessione successiva.
Connettersi
Seleziona una sessione e fai clic su Connetti. Lo stato della connessione mostra se il socket è disconnesso, in connessione, aperto, in chiusura o chiuso.
Usa Disconnetti prima di cambiare target o dettagli dell'handshake. Riconnettiti dopo aver modificato l'URL o le intestazioni per testare un nuovo percorso del server o un contesto autenticato.
La connessione completa solo l'handshake WebSocket. Molte applicazioni richiedono poi un frame di autenticazione o inizializzazione prima di accettare messaggi applicativi. Usa il primo messaggio acquisito del client come riferimento, attendi la sua conferma e solo allora invia il messaggio modificato. I cookie, gli URL firmati e i token acquisiti potrebbero essere scaduti.
Inviare messaggi
Usa l'editor dei messaggi per modificare un payload e inviarlo tramite la sessione selezionata. I payload di testo vengono inviati come frame di testo WebSocket.
Passa alla modalità binaria per byte esadecimali. Ripeti primo messaggio WebSocket acquisito aiuta a inviare di nuovo l'inizializzazione, e Ripeti sequenza acquisita in uscita invia in ordine i messaggi acquisiti del client. Controlla le risposte nella cronologia anziché presumere che l'invio di una sequenza abbia ricreato lo stato dell'applicazione.
L'editor del protocollo supporta le modalità WebSocket grezzo e GraphQL gestito (graphql-transport-ws e il precedente graphql-ws). Scegli il protocollo usato dal target e fornisci i suoi parametri di connessione. Conserva l'intestazione di sottoprotocollo originale quando richiesta; richiedere il protocollo sbagliato può far fallire l'upgrade.
Aggiorna indicazioni temporali è disattivo per impostazione predefinita. Attivalo solo per richieste non firmate che richiedono indicazioni temporali aggiornate: cambiare un URL o un payload firmato può invalidarne la firma. Riconnessione automatica riprova dopo una disconnessione, ma una nuova connessione può comunque richiedere autenticazione a livello applicativo.
I messaggi acquisiti inviati dalla cronologia mantengono il payload originale come punto di partenza, così puoi cambiare un campo alla volta e confrontare il comportamento.
Cronologia dei messaggi
La cronologia registra i frame inviati e ricevuti per la sessione selezionata.
| Colonna | Descrizione |
|---|---|
| Direzione | Se il frame è stato inviato dal client o ricevuto dal server. |
| Opcode | Tipo di frame, come testo, binario, ping, pong o chiusura. |
| Dimensione | Dimensione del payload. |
| Ora | Quando Ogma ha osservato il frame. |
Seleziona un messaggio per ispezionare il payload. I payload JSON vengono formattati quando possibile; il contenuto grezzo resta disponibile per un esame esatto.
Procedura di test
- Acquisisci un normale flusso WebSocket in Cronologia WebSocket / SSE.
- Invia un messaggio interessante del client a Ripetizione WS.
- Riconnettiti e invia di nuovo il messaggio originale per confermare il comportamento di riferimento.
- Modifica un campo, token, ID o comando alla volta.
- Registra il comportamento confermato in Risultati o conserva appunti in Note.
Risoluzione dei problemi
| Sintomo | Cosa controllare |
|---|---|
| Upgrade rifiutato o vietato | URL, Origin, cookie, autorizzazione e valori firmati scaduti nella query. |
| Sottoprotocollo non valido o non richiesto | Confronta le intestazioni di upgrade con l'handshake acquisito e la modalità di protocollo selezionata. |
| La connessione riesce, poi si chiude | Ispeziona il messaggio di sistema/chiusura e invia il frame di inizializzazione o autenticazione richiesto. |
| Messaggio inviato ma nessuna risposta utile | Conferma gli ID di sottoscrizione, i messaggi precedenti, l'autenticazione e lo stato dell'applicazione; il trasporto WebSocket non ricrea automaticamente una sessione di browser. |
Con MCP, usa gli strumenti dedicati di elenco/lettura dei messaggi di Ripetizione WS e di disconnessione. Gli strumenti della cronologia acquisita leggono una trascrizione diversa; consulta il riferimento degli strumenti MCP.