Quelle est la raison pour laquelle le navigateur ne répond pas après le retour du serveur WebSocket 401? Comment le résoudre?

Netty Websocket Server renvoie 401, Solution non réactive du navigateur

Lorsque vous utilisez Netty pour créer un serveur WebSocket et effectuer une vérification du jeton, si le jeton n'est pas valide, le serveur renvoie un code d'état 401 et ferme la connexion, mais le navigateur peut ne pas réagir en aucune façon. Cet article analyse ce problème et fournit des solutions.

Description du problème

Les jetons sont nécessaires pour développer des serveurs WebSocket à l'aide de NetTy. Lorsque la vérification des jetons échoue, le serveur renvoie 401 et ferme la connexion, mais le navigateur ne répond pas et le front-end ne peut pas connaître la raison de la fermeture de la connexion. Exemple de code côté serveur:

 private void httpResponse401 (ChannelHandlerContext ctx, fullhttprequest request) {
    FullHttpResponse Response = new DefaultfullHttpResponse (request.protoColVersion (), httpResponSestatus.unAuthorized);
    réponse.Headers (). set (httpheadernames.content_length, 0);
    ctx.writeAndFlush (Response) .AddListener (ChannelfUTUreListener.close);
    REFORENCECOUNTUTIL.Release (demande);
}

Code JavaScript frontal:

 var socket = nouveau WebSocket ("ws: //127.0.0.1: 18080 / ws? token = xxxx");

Bien que le serveur renvoie 401 et ferme la connexion, le navigateur ne répond en aucune façon.

Solution

Le navigateur ne répond pas car la réponse 401 est ignorée pendant la phase de poignée de main WebSocket. Nous devons le traiter pendant la phase de poignée de main ou après l'établissement de la connexion.

Solution 1: Retour 401 Réponse pendant la phase de poignée de main

Dans la phase de poignée de main WebSocket (phase de demande HTTP), si la vérification des jetons échoue, la réponse HTTP 401 sera directement retournée pour éviter d'établir une connexion WebSocket. Modifiez le code côté serveur:

 if (! validateToken (demande)) {
    FullHttpResponse Response = new DefaultfullHttpResponse (httpversion.http_1_1, httpResponsestatus.unAuthorized);
    réponse.Headers (). Set (httpheadernames.content_type, "text / plain; charset = utf-8");
    Response.Headers (). Set (httpheadernames.content_length, réponse.Content (). ReadableBytes ());
    ctx.writeAndFlush (Response) .AddListener (ChannelfUTUreListener.close);
    retour;
}

Solution 2: Envoyez des messages personnalisés une fois la connexion établie

Si vous devez traiter 401 une fois la connexion WebSocket établie, vous pouvez envoyer un message personnalisé pour informer l'avant immédiatement après l'établissement de la connexion. Ajoutez un processeur personnalisé dans WebSocketServerProtocolHandler de Netty:

 channel.pipeline (). addLast (new WebSocketServerProtoColHandler ("/ ws") {
    @Outrepasser
    public void usereventtriggerred (canalsHandlerContext ctx, objet EVT) lève une exception {
        if (evt == WebsocketServerProtoColHandler.serverHandshakeStateEvent.handshake_complete) {
            if (! validateToken ()) {
                ctx.writeAndflush (new TextWebsocketFrame ("401 Unauthorized").
            }
        }
        super.UseReventTriggerred (CTX, EVT);
    }
});

Le code JavaScript frontal doit écouter les événements onmessage :

 socket.onMessage = fonction (événement) {
    if (event.data === "401 non autorisé") {
        Console.log ("Connexion fermée, raison: 401 non autorisé");
        socket.close ();
    }
};

Grâce à la méthode ci-dessus, le navigateur peut traiter correctement le code d'état 401, et le frontal peut également recevoir des informations de rétroaction correspondantes, résolvant ainsi le problème de la non-réponse du navigateur. Quelle solution à choisir dépend du scénario d'application et des exigences spécifiques.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!