1

幅広いブラウザー互換性を必要とするNode.js/Socket.IOを使用するアプリケーションで作業しているため、クライアントがブラウザーでWebSocketをサポートしていない可能性があります。基盤となるトランスポートに関係なく、ユーザーを認証するための最も堅牢な方法を知りたいと思いました。

理想的な接続/ハンドシェイクでsessionIDを使用してCookieを送信する例はいくつかありますが、送信されるCookieが異なるため、これがFlashSocketsで機能しないのではないかと心配しています。

もう1つの方法は、ユーザーが認証するときにクライアントにSessionIDを保存させ、ユーザーがSocket接続を必要とするときに、最初のメッセージとしてセッションIDを送信することです。このアプローチの問題は、完全な接続を確立するオーバーヘッドが発生することです。これは、負荷またはセキュリティの観点からは理想的ではありません。

クライアントとサーバー間で使用されている基本的なトランスポートメカニズムに関係なく、接続/ハンドシェイクフェーズ（つまり、接続されたソケットを介してトークンを送信しない）でSocket.IOを使用する最適な認証パターンは何ですか？

4

1 に答える 1

0

私の考えでは、開いているソケットで認証を送信することは避けられません。読み取り専用のパブリックストリーミングを提供している場合を除き、ソケットの使用をアプリケーションのリアルタイムの側面に制限している場合でも、そのソケットを内部にあるものにリンクする必要があります。

Express / Redisなどの別のメカニズムを介して認証し、承認が有効な場合にのみソケット接続を開くようにクライアントに指示する（ソケットを介した最初の通信としてセッションIDを送信する）ことで、接続のオーバーヘッドを減らすことができます。これは、クライアントコードで手動で行う必要があります。確かに、Socket.IO接続を介してCookieが自動的に送信されることはありません。無効なセッションIDを渡すソケットをすぐに切断したり、セッションIDなしでリクエストを送信したりできます。また、DoS攻撃が懸念される場合は、これらの接続に対してはるかに厳密なタイムアウトを設定できます。これを実装する方法のサンプルコードについては、Socket.IO認証を参照してください。

于 2012-11-10T01:38:19.607 に答える