まず、socket.io の代わりに別の websocket ライブラリを使用します。socket.io の開発者は現在 engine.io に取り組んでおり、socket.io はあまり積極的にメンテナンスされていないようです。次のリンクで説明されている問題の多くを経験しましたが、sockjs に移行してから問題は発生していません。
http://www.quora.com/Sock-js/What-are-the-pros-and-cons-of-socket-io-vs-sockjs?share=1
https://github.com/LearnBoost/socket .io/issues
https://github.com/ether/etherpad-lite/issues/1798
http://baudehlo.com/2013/05/07/sockjs-multiple-channels-and-why-i-dumped-socket -io/
sockjs の上に独自のカスタム イベントを実装する必要があるかもしれませんが、それは簡単なことです。すでに redis を使用しているように思われるので、rooms と pub/sub の実装も非常に簡単なはずです。
トークンベースのソケット認証を行う方法は次のとおりです。
- 最初に、クライアントはサーバーに HTTP 要求を送信してトークンを要求します。これにより、express のミドルウェアを介してリクエストがルーティングされ、セッション データに簡単にアクセスできるようになります。これは、アカウントまたはセッション データにアクセスするためにパスポートと対話する場所です。ユーザーがログインしている場合は、UUID を生成し、セッション データをキーと値のペアとして redis に保存します。キーは UUID で、値は文字列化されたセッション/アカウント データです。UUID のみをクライアントに送り返します。
- クライアントが最初に Websocket 接続を作成するときに、未認証としてマークするソケットにフラグを設定します。
- ソケットにメッセージが届いたら、ソケットが認証されているかどうかを確認します。そうでない場合は、メッセージ内のトークンを確認してください。存在しない場合は、接続を切断します。存在する場合は、トークンによってキー付けされたキーと値のペアを redis にクエリします。redis が何らかのデータを返す場合、そのユーザーのセッション データが得られ、それをソケットにアタッチし、ソケットを認証済みとしてマークできます。トークンによってキー化された redis に何もない場合は、接続を終了します。
これで、ソケットで操作を実行するときに、そのユーザーのセッション データにアクセスできるようになります。