Les en-têtes HTTP dans les Websockets client API

Dirait qu'il est facile d'ajouter des en-têtes HTTP personnalisés à votre client websocket avec n'importe quel en-tête HTTP client qui prend en charge ce, mais je ne trouve pas comment le faire avec l'API JSON.

Pourtant, il semble qu'il devrait y avoir un soutien ces en-têtes dans la spec.

Quelqu'un a une idée sur comment faire? 

var ws = new WebSocket("ws://example.com/service");

Plus précisément, j'ai besoin d'être en mesure d'envoyer un HTTP en-tête d'Autorisation.

  • Je pense qu'une bonne solution est de permettre à la WebSocket pour se connecter sans autorisation, mais ensuite, bloquer et d'attendre sur le serveur pour recevoir l'autorisation de la webSocket qui transmet les informations d'autorisation en son événement onopen.
  • La suggestion de @Motes semble être le meilleur ajustement. Il était très facile de faire une autorisation d'appel de onOpen qui vous permet d'accepter ou de rejeter la prise basé sur l'autorisation de la réponse. J'ai d'abord tenté l'envoi de jeton d'authentification dans la Sec-WebSocket-en-tête de Protocole, mais qui se sent comme un hack.
InformationsquelleAutor Julien Genestoux | 2010-12-05
  1. 168

    Mis à jour 2x

    Réponse courte: Pas, seulement le chemin et le champ de protocole peut être spécifié.

    Plus réponse:

    Il n'y a pas de méthode dans le code JavaScript, Les WebSockets API pour la spécification des en-têtes supplémentaires pour le client/navigateur pour envoyer. Le chemin d'accès HTTP ("GET /xyz") et le protocole de l'en-tête (ou"Sec-WebSocket-Protocole") peut être spécifié dans le WebSocket constructeur.

    La Sec-WebSocket-en-tête de Protocole (qui est parfois étendue à être utilisés dans les websocket d'authentification spécifique) est généré à partir de la deuxième argument optionnel de la WebSocket constructeur:

    var ws = new WebSocket("ws://example.com/path", "protocol");
var ws = new WebSocket("ws://example.com/path", ["protocol1", "protocol2"]);

    Les résultats ci-dessus dans les en-têtes suivants:

    Sec-WebSocket-Protocol: protocol

    et

    Sec-WebSocket-Protocol: protocol1, protocol2

    Un modèle commun pour la réalisation de WebSocket d'authentification/autorisation est de mettre en place un système de billetterie où la page hébergeant le WebSocket client demande un ticket de du serveur, puis passe ce billet en cours de connexion WebSocket le programme d'installation dans l'URL/chaîne de requête, dans le champ protocole, ou que le premier message après que la connexion est établie. Ensuite, le serveur ne permet que la connexion si le billet est valide (il existe, n'a pas été déjà utilisé, l'adresse IP du client codées dans le billet matches, l'horodatage dans le billet est récente, etc). Voici un résumé de WebSocket de la sécurité de l'information: https://devcenter.heroku.com/articles/websocket-security

    L'authentification de base était autrefois une option, mais elle est obsolète et navigateurs modernes ne pas envoyer l'en-tête, même si elle est spécifiée.

    Basic Auth Info (Obsolète):

    L'en-tête d'Autorisation est généré à partir du nom d'utilisateur et le mot de passe (ou tout simplement le nom d'utilisateur) domaine de la WebSocket URI:

    var ws = new WebSocket("ws://username:[email protected]")

    Les résultats ci-dessus dans la suite de l'en-tête avec la chaîne "nom d'utilisateur:mot de passe" base64:

    Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

    J'ai testé l'authentification basique de Chrome 55 et Firefox 50 et vérifié que le basic auth info est en effet négocié avec le serveur (cela peut ne pas fonctionner dans Safari).

    Grâce à Dimitri Frank pour le basic auth réponse

    • J'ai rencontré le même problème. Dommage que ces normes sont si mal intégrée. Vous attendez qu'ils regardent la XHR API pour trouver les exigences (depuis les WebSockets et XHR sont liés) pour les WebSockets de l'API, mais il semble qu'ils sont tout simplement le développement de l'API sur une île en elle-même.
    • rejoindre le HyBi groupe de travail et le proposer. Le groupe est ouvert au public et il est en cours de travail pour les prochaines versions du protocole.
    • Serait-ce une mauvaise idée d'utiliser l'en-tête de Protocole valeurs à envoyer (par exemple) une autorisation de hachage? Lire ici - stackoverflow.com/questions/7363095/... - ça ne semble pas une mauvaise idée, mais je me demande ce que seront les conséquences.
    • si vous contrôler entièrement le serveur, c'est une option. Les plus courants l'approche est de générer un ticket/jeton normal de votre serveur HTTP et ensuite au client d'envoyer le ticket/jeton (soit sous forme d'une chaîne de requête dans le websocket chemin d'accès ou le premier message websocket). Le serveur websocket puis valide le ticket/jeton est valide (n'a pas expiré, n'a pas déjà été utilisé, venant de la même adresse IP que lors de sa création, etc). Aussi, je crois que la plupart des websockets les clients prennent en charge l'authentification basique (peut-être pas assez pour vous). Plus d'infos: devcenter.heroku.com/articles/websocket-security
    • Digest authentification fonctionne avec les WebSockets ainsi.
    • Selon rfc6455: Protocole WebSocket est conçue pour remplacer les existants mode de communication bidirectionnelle, technologies qui utilisent le protocole HTTP comme un transportlayer de bénéficier de l'infrastructure existante (proxy, filtrage,authentification). [...........] Le Protocole WebSocket tente de répondre aux objectifs de l'existant bidirectionnel HTTP technologies dans le contexte de l'existant HTTP infrastructure; en tant que tel, il est conçu pour fonctionner sur HTTP les ports 80 et 443 ainsi que des proxys HTTP et les intermédiaires, même si cela implique une certaine complexité spécifique à l'environnement actuel.
    • Je suppose que c'est par la conception. J'ai l'impression que la mise en œuvre est intentionnellement emprunt de HTTP, mais de les garder séparés autant que possible par la conception. Le texte dans les specificatio poursuit: "Cependant, la conception ne se limite pas WebSocket HTTP, et les futures implémentations pourrait utiliser une simple poignée de main sur un port dédié sans avoir à réinventer l'ensemble du protocole. Ce dernier point est important, car les tendances du trafic de messagerie interactive ne pas correspondre à la norme trafic HTTP et peut induire des charges inhabituelles sur certains composants."
    • 2016 et c'est encore le cas 🙁
    • Si nous ne pouvons pas ajouter un en-tête personnalisé, pouvons-nous au moins de modifier un non-tête personnalisé, par exemple, "Témoin"?
    • Il y a un moyen de définir à la Base de l'Autorisation d'en-tête HTTP, voir ma réponse.
    • Malheureusement, cela ne semble pas fonctionner dans le Bord. Merci, MS :/
    • ws://username:[email protected] ce modèle ne fonctionne pas sous Safari, mais fonctionne dans chrome, ff
    • comment définir une "connexion" header? merci
    • N'Basic auth encore du travail? J'ai testé Chrome et Firefox, et il n'y a pas d'en-tête d'Autorisation.
    • Basic auth ne fonctionne plus que l'approche est obsolète. developer.mozilla.org/en-US/docs/Web/HTTP/...
    • Quand j'ai essayé d'utiliser "Sec-WebSocket-Protocole" dans chrome, j'ai eu WebSocket: Error during WebSocket handshake: Sent non-empty 'Sec-WebSocket-Protocol' header but no response was received erreur.
    • J'ai mis à jour la réponse à montrer que l'authentification basique est obsolète. La raison pour laquelle vous obtenez cette erreur est parce que le serveur a besoin pour soutenir le protocole de terrain et de répondre avec la valeur de protocole qui a été sélectionné.
    • avez-vous un lien où il est dit basic auth est obsolète?
    • 2019 et c'est encore le cas 🙁

    InformationsquelleAutor kanaka
  2. 31

    HTTP en-tête d'Autorisation problème peut être résolu avec les éléments suivants:

    var ws = new WebSocket("ws://username:[email protected]/service");

    Ensuite, une bonne Base de l'Autorisation en-tête HTTP de la condition username et password. Si vous avez besoin d'Autorisation de Base, alors vous êtes tous ensemble.

    Je veux utiliser Bearer cependant, et j'ai eu recours à l'astuce suivante: - je me connecter au serveur comme suit:

    var ws = new WebSocket("ws://[email protected]/service");

    Et quand mon code sur le serveur reçoit l'Autorisation de Base de l'en-tête avec les non-vide nom d'utilisateur et mot de passe vide, puis il interprète le nom d'utilisateur comme un jeton.

    • Je suis en train d'essayer la solution proposée par vous. Mais je ne suis pas en mesure de voir l'en-tête d'Autorisation d'être ajoutée à ma demande. Je l'ai essayé, à l'aide de différents navigateurs Chrome par exemple V56, Firefox V51.0 je suis en cours d'exécution de mon serveur sur mon localhost. ainsi, le websocket url est "ws://myusername:mypassword@localhost:8080/mywebsocket". Toute idée de ce qui pourrait être mauvais? Merci
    • Est-il sécuritaire de transfert de jeton par le biais de l'url?
    • la même chose est discutable pour l'Authentification de Base droit?
    • Ne serait-ce pas la base en-têtes d'authentification être masqué si la connexion sécurisée est utilisée, tandis que l'URL serait ouvert à tout le monde l'espionnage?
    • Vide/ignorés nom d'utilisateur et mot de passe non vide comme jeton peut être mieux parce que les noms d'utilisateur peut être connecté.
    • Je suis d'accord avec @LearnToLive - j'ai utilisé cela avec wss (par exemple wss://user:[email protected]/ws) et n'ai obtenu aucune Authorization en-tête sur le côté serveur (à l'aide de la version Chrome 60)
    • Dans une connexion sécurisée, tout, y compris l'URL est caché à l'intérieur d'un tunnel sécurisé.
    • J'ai le même problème que @LearnToLive et @user9645; ni chrome ni firefox sont l'ajout de l'en-tête d'autorisation lorsque l'URI est dans le wss://user:pass@host format. Ce n'est pas pris en charge par les navigateurs, ou est-ce que quelque chose va mal avec la poignée de main?
    • Même problème ici. Pas d'en-tête d'Autorisation. C'est l'enfer.
    • même chose que @DavidKaczynski ce que quelqu'un sait pourquoi? Peut-être la nouvelle version de chute de la charge?
    • c'est incorrect! L'URL n'est pas chiffré. Même le même en HTTPS.
    • L'utilisation de ces url http://username:[email protected] est amorti. developer.mozilla.org/en-US/docs/Web/HTTP/Authentication. Des thats peut-être la raison pour laquelle cela ne fonctionne pas avec les websockets, soit!

    InformationsquelleAutor Dmitry Frank
  3. 20

    Plus d'une solution alternative, mais tous les navigateurs modernes envoyer le domaine des cookies avec la connexion, donc à l'aide de:

    var authToken = 'R3YKZFKBVi';

document.cookie = 'X-Authorization=' + authToken + '; path=/';

var ws = new WebSocket(
    'wss://localhost:9000/wss/'
);

    Jusqu'à la fin avec la demande d'en-têtes de connexion:

    Cookie: X-Authorization=R3YKZFKBVi
    InformationsquelleAutor Tim
  4. 16

    Vous ne pouvez pas ajouter des en-têtes, mais, si vous avez juste besoin de passer des valeurs pour le serveur au moment de la connexion, vous pouvez spécifier une partie de chaîne de requête de l'url:

    var ws = new WebSocket("ws://example.com/service?key1=value1&key2=value2");

    Que l'URL est valide, mais bien - sûr, vous aurez besoin de modifier votre code serveur pour l'analyser.

    • devez être prudent avec cette solution, la chaîne de requête peuvent être interceptées, enregistré dans les procurations, etc. donc en passant d'informations sensibles (utilisateurs / mot de passe / les jetons d'authentification) de cette façon ne sera pas assez sécurisé.
    • avec WSS la chaîne de requête devrait probablement être sûr
    • ws est du texte brut. À l'aide de ws protocole rien ne peut être interceptée.
    • il n'est pas sûr de l'utilisation de la chaîne de requête, il n'est pas chiffré le même s'applique à HTTPS, mais depuis "ws://..." protocole est utilisé, il n'a vraiment pas d'importance.
    • la chaîne de requête est chiffré, mais il y a une foule d'autres raisons de ne pas ajouter des données sensibles comme des paramètres de requête URL stackoverflow.com/questions/499591/are-https-urls-encrypted/... & blog.httpwatch.com/2009/02/20/... comme les refs
    InformationsquelleAutor Gabriele Carioli
  5. 12

    Vous ne pouvez pas envoyer l'en-tête personnalisé lorsque vous souhaitez établir les WebSockets connexion à l'aide de JavaScript API Websocket.
    Vous pouvez utiliser Subprotocols en-têtes à l'aide de la deuxième WebSocket constructeur de la classe:

    var ws = new WebSocket("ws://example.com/service", "soap");

    et puis vous pouvez obtenir le Subprotocols en-têtes à l'aide de Sec-WebSocket-Protocol clé sur le serveur.

    Il y a aussi une limitation, votre Subprotocols les en-têtes de valeurs ne peut pas contenir une virgule (,) !

    • Peut un Jwt contenir une virgule?
    • Je ne le crois pas. JWT se compose de trois base64 charges, chacun séparé par un point. Je crois que cela exclut la possibilité d'une virgule.
    • Je l'ai fait et cela fonctionne - se sent juste bizarre. merci
    • suggérez-vous que nous utilisons le Sec-WebSocket-Protocol en-tête en tant que suppléant de la Authorization en-tête?
    InformationsquelleAutor Saeed Zarinfam
  6. 5

    L'envoi d'en-tête d'Autorisation n'est pas possible.

    De la fixation d'un jeton de paramètre de requête est une option. Toutefois, dans certaines circonstances, il peut être souhaitable d'envoyer votre principale jeton de connexion en texte brut comme un paramètre de requête, car il est plus opaque que l'utilisation d'un en-tête et finira par être connecté whoknowswhere. Si cela soulève des préoccupations en matière de sécurité pour vous, une alternative est d'utiliser un secondaire JWT jeton juste pour le web socket trucs.

    Créer un point de terminaison REST pour la génération de ce JWT, qui peut bien sur être utilisé par des utilisateurs authentifiés avec votre jeton de connexion (transmis via l'en-tête). Le web socket JWT peut être configuré différemment de votre jeton de connexion, par exemple, avec un court délai, de sorte qu'il est plus sûr d'envoyer une requête de paramètre de votre demande de mise à niveau.

    De la création d'un JwtAuthHandler pour le même parcours que vous enregistrez le SockJS eventbusHandler sur. Assurez-vous que votre auth gestionnaire est inscrit en premier, de sorte que vous pouvez vérifier sur le web socket jeton à l'encontre de votre base de données (JWT devrait être en quelque sorte lié à votre utilisateur dans le backend).

    • C'était la seule solution que je pouvais venir de la Passerelle API websocket. Mou fait la même chose avec leurs RTM API et ils ont un délai d'attente de 30 secondes.
    InformationsquelleAutor Norbert Schöpke
  7. 1

    Totalement piraté comme ça, grâce à kanaka de réponse.

    Client:

    var ws = new WebSocket(
    'ws://localhost:8080/connect/' + this.state.room.id, 
    store('token') || cookie('token') 
);

    Serveur (à l'aide Koa2 dans cet exemple, mais il devrait être similaire où):

    var url = ctx.websocket.upgradeReq.url; //can use to get url/query params
var authToken = ctx.websocket.upgradeReq.headers['sec-websocket-protocol'];
//Can then decode the auth token and do any session/user stuff...
    • N'est-ce pas juste passer votre jeton dans la section où votre client est censé demander à un ou plusieurs des protocoles spécifiques? Je peux le faire fonctionner, pas de problème, mais j'ai décidé de ne pas le faire et plutôt faire ce que Motes proposé et de bloquer jusqu'à ce que le jeton d'authentification est envoyé sur le onOpen(). La surcharge de la demande du protocole de l'en-tête semble mauvais pour moi, et comme mon API est pour la consommation publique, je pense que ça va être un peu déroutant pour les consommateurs de mon API.
    InformationsquelleAutor Ryan Weiss
  8. -2

    Techniquement, vous pourrez envoyer ces en-têtes grâce à la fonction de connexion avant que le protocole de la phase de mise à niveau. Cela a fonctionné pour moi dans un nodejs projet:

    var WebSocketClient = require('websocket').client;
var ws = new WebSocketClient();
ws.connect(url, '', headers);
    • Je voudrais que les gens d'ajouter des commentaires quand ils downvote une réponse, comme StackOverflow leur demande de! Il est difficile de dire si c'était downvoted par certains ignorant dont la configuration particulière, il ne fonctionne pas, ou si cela ne fonctionnera certainement pas dans toutes les circonstances. Dans le même temps, George: Il est douteux que cela fonctionne dans les navigateurs. Si cela fonctionne dans nodejs ou certains autres JS moteur, c'est un détail important à ajouter à votre réponse.
    • C'est pour le client websocket dans la ngp (pour le nœud). npmjs.com/package/websocket dans l'Ensemble, ce serait exactement ce que je recherche, mais dans le navigateur.
    • C'est downvoted parce que ce paramètre en-têtes sur le protocole WebSocket couche, et la question est à propos des en-têtes HTTP.
    • "headers doit être null ou un objet de préciser les autres arbitraire-têtes de requête HTTP à envoyer avec la demande." à partir de WebSocketClient.md; par conséquent, la headers voici HTTP couche.
    • Aussi, toute personne qui veut personnaliser les en-têtes doivent garder à l'esprit la signature de la fonction de la connect méthode, décrite comme connect(requestUrl, requestedProtocols, [[[origin], headers], requestOptions]), c'est à dire la headers devrait être fourni avec requestOptions, par exemple, ws.connect(url, '', headers, null). Seul le origin chaîne peut être ignoré dans ce cas.
    • Cette conduis-moi vers le bas le chemin d'accès correct pour le nœud. Nulle part dans l'OP t-il de spécifier de manière explicite (implique uniquement) la réponse doit être pour le navigateur.

    InformationsquelleAutor George