Socket.io-client: ハンドシェイクヘッダーへのアクセスを許可する

作成日 2014年03月14日  ·  19コメント  ·  ソース: socketio/socket.io-client

接続を確立するときに、io.connect(url、{query: 'key = value'})を介してクエリ文字列に「アクセス」できます。

私はヘッダーで同様のことができると期待していました。

これを使用して、トークン認証を使用してwebapiを構築したいと思います。

最も参考になるコメント

+1これに関する更新はありますか?

全てのコメント19件

これも欲しいです。

リクエストを行うときは、ヘッダーを「設定」すると言ったほうがいいと思います。

ヘッダーの変更を予期する際の問題は、特定のトランスポートがそれらを許可しないことです。

  • WebSocketはカスタムヘッダーを許可しません
  • JSONPポーリング(別名<script> )はそれらを許可しません

特定のヘッダーを設定できる唯一の条件は、socket.ioにXHRポーリングのみを使用するように強制することです。

クライアントを認証できるようなものを期待していました。 クエリ文字列で認証トークン(またはパスワード)を送信することはお勧めできません。

代わりに、本文でクレデンシャルを送信するモジュールを作成しました: https ://github.com/invisiblejs/socketio-auth

@rauchgはそれをさらに説明できますか、 https ://github.com/Automattic/socket.io/wiki/authorizing#handshakingのドキュメントには次のように書かれています。

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

なぜなら:

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

以来:

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

それで、これは、ハンドシェイクがXHRにあったとしても、WS接続を確立できることを示しているのではないので、承認に要求ヘッダーを使用しても問題ありませんか?

ある段階でコードを持っていたようですhttps://github.com/Automattic/socket.io-client/issues/344#issuecomment-9424237

ですから、問題があったと思いますので、削除されたように見えるCookieを除いて、メインリポジトリに到達することはありませんでした。 その場合、少し誤解を招くようなサーバーのドキュメントを更新することをお勧めしますhttp://socket.io/docs/server-api/#namespace#use%28fn:function%29:namespace

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

これは、Cookie(つまりヘッダー)を認証に使用できることを示しています。 また、メインサイトの廃止された認証ウィキドキュメントに、認証の例と他のアプローチの問題についての言及を追加します。これは一般的なシナリオであると確信しています。

これに対するある程度の解決のために+1。 トークン認証のヘッダーを設定するためのより良いアクセスを期待していたので、ドキュメントと例は私の時間を浪費しました。

+1。 ヘッダーへのアクセスを可能にするengine.ioクライアントの今後のリリースがあります。これにより、この問題の解決が容易になります。
https://github.com/socketio/engine.io-client/pull/379

これはクライアントJSライブラリからも利用できますか? また、実際に侵入したことはありますか? マージされているように見えますが、動作していないと思います。間違っている可能性があります

+1。 ブラウザクライアントを認証する必要がある同様の状況に遭遇しました。 socket.io-clientはそれを許可していないようです。

+1これに関する更新はありますか?

これに関する更新はありますか?

これに関する更新はありますか?

2.0.0extraHeadersオブジェクトを提供できるようになりました。

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

ここのドキュメントに追加されました。

2.0.0extraHeadersオブジェクトを提供できるようになりました。

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

ここのドキュメントに追加されました。

express corsを使用していますが、これで次のCORSエラーが発生します:

プリフライトリクエストへの応答がアクセス制御チェックに合格しません:HTTPokステ​​ータスがありません。

@ 4nubhav次のようなhandlePreflightRequest関数を渡す必要があります:

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

2.0.0extraHeadersオブジェクトを提供できるようになりました。

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

ここのドキュメントに追加されました。

ソケットサーバーで.of("/path")を使用してから、URLを宣言する場所で何をしますか。

@ 4nubhavサーバー側でhandlePreflightRequestを使用してそのヘッダーを許可する必要があります。

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

更新:Socket.IO v3では、 transportOptionsは不要になり、次のように使用できます。

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

CORSのドキュメント:

  • v2: https ://socket.io/docs/v2/handling-cors/
  • v3: https ://socket.io/docs/v3/handling-cors/
このページは役に立ちましたか?
0 / 5 - 0 評価