2012-05-12 5 views
8

voglio fornire un errore significativo per il client quando sono collegati troppi utenti o quando ci si connette da un dominio non supportato, quindi ...nodejs + WebSockets - rifiutano il collegamento con un messaggio

ho scritto del codice del server WebSocket:

var http = require('http'); 
var httpServer = http.createServer(function (request, response) 
{ 
    // i see this if i hit http://localhost:8001/ 
    response.end('go away'); 
}); 

httpServer.listen(8001); 

// https://github.com/Worlize/WebSocket-Node/wiki/Documentation 
var webSocket = require('websocket'); 
var webSocketServer = new webSocket.server({ 'httpServer': httpServer }); 

webSocketServer.on('request', function (request) 
{ 
    var connection = request.reject(102, 'gtfo'); 
}); 

E alcuni codice client WebSocket:

var connection = new WebSocket('ws://127.0.0.1:8001'); 
connection.onopen = function (openEvent) 
{ 
    alert('onopen'); 
    console.log(openEvent); 
}; 
connection.onclose = function (closeEvent) 
{ 
    alert('onclose'); 
    console.log(closeEvent); 
} 
connection.onerror = function (errorEvent) 
{ 
    alert('onerror'); 
    console.log(errorEvent); 
}; 
connection.onmessage = function (messageEvent) 
{ 
    alert('onmessage'); 
    console.log(messageEvent); 
}; 

Tutto che ottenga è alert('onclose'); con un CloseEvent oggetto registrato in la console senza alcun codice di stato o messaggio che riesco a trovare. Quando mi connetto tramite ws://localhost:8001, la callback httpServer non entra in gioco, quindi non riesco a prenderla lì. Il RFC suggerisce che dovrei essere in grado di inviare qualsiasi codice di stato diverso da 101 quando c'è un problema, ma Chrome genera un errore nella console Unexpected response code: 102. Se chiamo request.reject(101, 'gtfo'), il che implica che ho avuto successo mi viene un errore di stretta di mano, come mi aspetterei.

Non sono proprio sicuro di cos'altro posso fare. Non è proprio possibile ora ottenere la risposta del server nell'implementazione WebSocket di Chrome?

ETA: Ecco un brutto scherzo nel frattempo, spero che non sia quello che devo finire a fare.

var connection = request.accept(null, request.origin); 
connection.sendUTF('gtfo'); 
connection.close(); 
+0

l'URL ws: //127.0.0.1: 8001 corrisponde all'URL che ha servito la pagina? – akonsu

+0

Intendo la pagina che contiene il codice cliente. – akonsu

+0

@akonsu che significa che si trova sullo stesso dominio? no, lo sto eseguendo localmente file: ///, che non è un problema dato che non sto convalidando 'request.origin'. – Langdon

risposta

11

Sono l'autore di WebSocket-Node e ho anche postato questa risposta alla questione relativa su GitHub: https://github.com/Worlize/WebSocket-Node/issues/46

Purtroppo, il protocollo WebSocket non prevede alcun meccanismo specifico per fornire un Chiudi codice o motivo in questa fase quando respingi una connessione client. Il rifiuto è sotto forma di una risposta HTTP con uno stato HTTP di qualcosa come 40x o 50x. La specifica lo consente, ma non definisce un modo specifico in cui il client deve tentare di individuare eventuali messaggi di errore specifici da una tale risposta.

In realtà, le connessioni devono essere rifiutate in questa fase solo quando si rifiuta un utente da un'origine non consentita (ad esempio, qualcuno da un altro sito Web sta tentando di connettere gli utenti al server Websocket senza autorizzazione) o quando un utente non lo fa avere il permesso di connettersi (cioè non hanno effettuato il login). Il secondo caso dovrebbe essere gestito da un altro codice sul tuo sito: un utente non dovrebbe essere in grado di tentare di connettere la connessione web se non ha effettuato il login.

Il codice e la ragione che WebSocket-Node ti permette di specificare qui sono un codice di stato HTTP (ad es. 404, 500, ecc.) e un motivo per includere come risposta un'intestazione HTTP "X-WebSocket-Reject-Reason" non standard. È utile soprattutto quando si analizza la connessione con uno sniffer di pacchetti, come WireShark. Nessun browser ha alcuna possibilità di fornire codici di rifiuto o motivi al codice JavaScript lato client quando una connessione viene rifiutata in questo modo, perché non è prevista nella specifica WebSocket.

+0

Grazie per l'intuizione. – Langdon