2017-03-08 3 views
0

を接続するとき、私は別のホスト上のAPIサーバーへのWebSocket接続送ります:私のフロントエンドがlocalhost:8080でホストされているのに対しない永続セッション別のホスト上のAPIに

new WebSocket("ws://localhost:3000") 

を。

session(Sinatraのenable :sessions)でキーを設定できますが、htmlページを更新するたびにデータが失われます。

フロントエンドがサーバーと同じホストを共有するセッションがいくつか必要ですか。それとも、私はこれを回避できる方法はありますか?ちなみに、フロントエンドはWebpackサーバー(ノード)上で実行されています。

私はまた、APIのルートルートhttp://localhost:3000ためcross_origin手当を追加し、クライアント(CoffeeScriptのこの例)でこれをやってみました:

$.get "http://localhost:3000", -> 
    new Websocket("ws://localhost:3000") 

私の思考は多分セッションは、「初期化するために必要なことでした"ws://の代わりにhttp://を超えていましたが、どちらも機能しませんでした。セッションは$.get "http://localhost:3000"リクエストでも機能しませんでした。ページを更新すると、毎回セッションがクリアされることが示されます。

+1

セッションはクッキーに基づいているため、おそらくセッションクッキーの永続性が問題です。 Webページと異なるホスト/ポートを使用すると、セッションCookieはサードパーティのCookieとなり、サードパーティのCookieには異なるセキュリティルールと設定が適用されます。あなたの設定やアドオンがサードパーティのCookieの永続性をブロックしていると思います。プレーンなwebSocket自体はクロスオリジン接続でうまく動作しますが、確立されたときにセッションクッキーをアタッチしようとすると、クッキーの永続性が必要になります。 – jfriend00

+0

クライアントまたはサーバーにコードを追加しますか? –

+0

まず、サードパーティのCookieがクライアントによって保持されているかどうかを調べる必要があります。そうでない場合は、クライアントの設定を修正して保持するか、別の起点を使用しないようにして、サードパーティのCookie設定に影響を与えないようにする必要があります。 – jfriend00

答えて

1

コメントで説明したように、ブラウザのサードパーティのセッションCookieに問題がある可能性があります。

これを回避するために使用できるスキームは次のとおりです。

  1. クライアントは初めてwebSocket接続を行います。
  2. サーバーは、sessionIDを付けてwebSocketメッセージを返します。
  3. クライアントは、第1のパーティのクッキー(たとえば、ホストウェブページのクッキー)にsessionIDを格納します。
  4. ユーザーヒットがリフレッシュされます。
  5. Webページは、ホストページのCookieにwebSocketセッションCookieが含まれているかどうかを確認します。そうであれば、そのセッションIDを含むwebSocket接続のURLを構築します。 `new Websocket(" ws:// localhost:3000?session = xyslkfas ")
  6. サーバがWebSocket接続を受け入れると、既にセッションが指定されている場合そうで、そのセッションがまだ有効であれば、そのセッションにその接続を接続します。そうでない場合は、新しいセッションを作成して手順2に戻ります。
+0

**注**:このアプローチでは、セッションIDが*接続ごとに*回転されていない限り、セキュリティ上のリスクが発生します。それ以外の場合、セッションIDはほとんどの仲介者によって要求とともに記録され、簡単にハイジャックすることができます。セッションはあまり安全ではないことは事実ですが、リクエストURLに情報を添付することは避けています。 – Myst

+0

@ミスト - 良い点。 sessionIDは常に期限切れで、特に長続きしないようにしてください。または、セッションIDがリレーエンジンに使用されると、ステップ2と同様に新しいものを作成してクライアントに送り返すことができ、古いものを無効にすることができます。または、再接続クエリパラメータbooleanを持つsessionIDなしでwebSocket接続を受け入れることができます。その後、他のメッセージが処理される前に資格情報を数秒以内に送信する必要があります。保護する必要がある/保護したいことに応じて、より安全にする方法はたくさんあります。 – jfriend00

+0

@Myst - また、OPがここでの認証について話していないことを考えると、このsessionIDはサーバーが以前のセッション情報に再接続しているwebSocketを関連付けることができるためです。したがって、これは認証された接続ではないように見えるので、セキュリティはここでの主な問題であってはなりません。認証情報がある場合、再接続は認証情報を送信してその方法で問題を解決できます。 – jfriend00

関連する問題