WebSocketがカスタムヘッダーをサポートできないのはなぜですか？
この質問はこれに関連しています 質問 私が尋ねました
要約すると、私は現在WebSocketで遊んでおり、WebSocket接続を使用してサーバーに接続しているクライアントを認証する方法を理解しようとしています。
通常の接続では、トークンベースの認証を使用します。基本的には、ログイン後にサーバーからトークンを取得します。サーバーにリクエストを行うたびに、Authenticationと呼ばれるカスタムヘッダーに入れます。そこ。
WebSocketの場合、WebSocketにはカスタムヘッダーがないため、これは機能しません。このトークンを渡すには2つのオプションがあります。
1）クエリ文字列にトークンを入れる-明らかに良いオプションではありません。トークンはサーバーなどで記録できます.
2）トークンをCookieに入れる-これは機能しますが、クライアントとサーバーが同じドメインにある場合のみです。また、クライアントがブラウザであり、Cookieをサポートする必要があるなど、他の制限もあります。
とにかく、他の質問は解決策を見つけることです、この質問はなぜこれが問題であるかを理解することです。 WebSocketがカスタムヘッダーをサポートしないのはなぜですか？見落としはほとんどありません。WebSocketとトークンベースの認証はどちらもかなり成熟したテクノロジーです。 WebSocket接続中にカスタムヘッダーを許可することで、何らかのセキュリティの問題はありますか？
WebSocketがカスタムヘッダーをサポートしないのはなぜですか？見落としになる可能性は低いです...
これは見落としのように見えることに同意します。
私の意見では、ブラウザー内でのWebSocketの実装はそもそも十分に検討されていなかったので、これは実際には私を驚かせません。最も重大な問題は、WebSocketが同じOriginポリシーまたは [〜＃〜] cors [〜＃〜] 制限を無視することです。つまり、サーバーは接続の起点（Origin header）それ以外の場合 Cross-Site WebSocket Hijacking が可能なためです。
このデフォルトで安全でない設計は、WebSocketよりも少し前に作成されたCORSのデフォルトで安全な動作とは対照的です。この明らかなセキュリティ問題を考えると、セキュリティに関する考慮事項がXHRのようにカスタムヘッダーを許可しないことに影響を与えたとは思えません。
WebSocketsプロトコル自体は、通常のHTTPリクエストと同様のHTTPハンドシェイクで始まるため、カスタムヘッダーをサポートしています。カスタムヘッダーを使用する機能がないのは、ブラウザーAPIのみです。