Socket.io-client: Zugriff auf Handshake-Header zulassen

Möchte das auch haben.

Ich denke, es wäre besser zu sagen, dass die Header bei der Anfrage gesetzt werden sollen.

Das Problem beim Erwarten von Header-Änderungen besteht darin, dass bestimmte Transporte sie nicht zulassen:

• WebSocket erlaubt keine benutzerdefinierten Header
• JSONP Polling (auch bekannt als <script> ) lässt sie nicht zu

Die einzige Bedingung, die es uns ermöglichen würde, bestimmte Header festzulegen, besteht darin, socket.io zu zwingen, nur XHR Polling zu verwenden

Ich hatte etwas Ähnliches erwartet, um die Clients authentifizieren zu können. Das Senden eines Autorisierungstokens (oder eines Kennworts) in der Abfragezeichenfolge ist keine gute Idee.

Ich habe ein Modul erstellt, um stattdessen Anmeldeinformationen im Text zu senden: https://github.com/invisiblejs/socketio-auth

@rauchg kannst du das weiter erklären, die Dokumentation unter https://github.com/Automattic/socket.io/wiki/authorizing#handshaking sagt:

The handshake is initiated with either an XHR request or a JSONP request

Denn:

Users might want to authorize the clients based on information from the headers or IP address

Seit:

Not all transports sends headers when they attempt to establish a real time connection with the server

Bedeutet dies nicht, dass es immer noch eine WS-Verbindung herstellen kann, obwohl Handshake in XHR war, und daher die Verwendung von Anforderungsheadern für die Autorisierung in Ordnung ist?

Es sieht so aus, als hätten Sie zu einem bestimmten Zeitpunkt Code dafür https://github.com/Automattic/socket.io-client/issues/344#issuecomment -9424237

Ich vermute also, dass es Probleme gab, sodass es nie in das Hauptrepo gelangt ist, abgesehen von Cookies, die so aussehen, als wären sie inzwischen entfernt worden. In diesem Fall wäre es gut, die etwas irreführende Serverdokumentation http://socket.io/docs/server-api/#namespace #use%28fn:function%29:namespace zu aktualisieren

var io = require('socket.io')();
io.use(function(socket, next){
  if (socket.request.headers.cookie) return next();
  next(new Error('Authentication error'));
});

Wie es angibt, können Cookies (dh Header) zur Authentifizierung verwendet werden. Und fügen Sie dem veralteten Authentifizierungs-Wiki-Dokument auf der Hauptseite einen Ersatz mit Beispielen für die Authentifizierung und Erwähnung von Problemen mit anderen Ansätzen hinzu, da ich sicher bin, dass es sich um ein häufiges Szenario handelt.

+1 für eine Lösung dazu. Die Dokumente und Beispiele haben meine Zeit in Anspruch genommen, da ich einen besseren Zugriff auf das Setzen von Headern auch für die Token-Authentifizierung erwartet hatte.

+1. Es gibt eine bevorstehende Version des engine.io-Clients, die den Zugriff auf Header ermöglicht, was die Lösung dieses Problems erleichtern sollte.
https://github.com/socketio/engine.io-client/pull/379

Ist dies auch in der Client-JS-Bibliothek verfügbar? Und ist es jemals wirklich reingekommen? Ich sehe, es ist zusammengeführt, aber ich glaube nicht, dass es betriebsbereit ist, könnte falsch sein

+1. Ich bin auf eine ähnliche Situation gestoßen, in der ich Browser-Clients authentifizieren muss. socket.io-client scheint dies nicht zuzulassen.

+1 Neuigkeiten dazu?

Irgendwelche Updates dazu?

Irgendwelche Updates dazu?

Seit 2.0.0 können Sie nun ein extraHeaders Objekt bereitstellen:

const socket = io({
  transportOptions: {
    polling: {
      extraHeaders: {
        'x-clientid': 'abc'
      }
    }
  }
});

Hier zur Dokumentation hinzugefügt.

Seit 2.0.0 können Sie nun ein extraHeaders Objekt bereitstellen:

const socket = io({
  transportOptions: {
    polling: {
      extraHeaders: {
        'x-clientid': 'abc'
      }
    }
  }
});

Hier zur Dokumentation hinzugefügt.

Ich erhalte den folgenden CORS-Fehler, obwohl ich cors mit express verwende:

Die Antwort auf die Preflight-Anfrage besteht die Zugriffskontrollprüfung nicht: Sie hat keinen HTTP-OK-Status.

@4nubhav Sie müssen eine handlePreflightRequest-Funktion wie folgt übergeben:

    handlePreflightRequest: (request, response) => {
        const headers = { ... };
        response.writeHead(200, headers);
        response.end();
    }

Seit 2.0.0 können Sie nun ein extraHeaders Objekt bereitstellen:

const socket = io({
  transportOptions: {
    polling: {
      extraHeaders: {
        'x-clientid': 'abc'
      }
    }
  }
});

Hier zur Dokumentation hinzugefügt.

Ich verwende .of("/path") auf dem Socket-Server, was ich dann mache, wenn ich die URL deklariere.

@4nubhav Sie sollten diesen Header mit handlePreflightRequest auf der Serverseite zulassen.

const options = {
    handlePreflightRequest: (req, res) => {
        res.writeHead(200, {
            'Access-Control-Allow-Headers': 'x-clientid', // <<< this
        });
        res.end();
     },
};
const io = require('socket.io')(server, options);

Update: In Socket.IO v3 wird das transportOptions nicht mehr benötigt, Sie können einfach verwenden:

const socket = io({
  extraHeaders: {
    'x-clientid': 'abc'
  }
});

Dokumentation für CORS:

• v2: https://socket.io/docs/v2/handling-cors/
• v3: https://socket.io/docs/v3/handling-cors/