Client Session State

Stores session state on the client.

How It Works

• 大なり小なり使うことになる

  • 最小

    • セッションIDを保持、セッション情報本体はサーバサイドで持つ

  • 最大

    • Client Session Stateでセッション情報全持ち、サーバはステートレスにできる
• データはDTOにシリアライズして転送する

• HTML Presentationにおいて、データの持ち方は3つ

  • URLパラメータ
  • hiddenフィールド
  • Cookie
  • 【補】HTML5でLocal Storage/Session Storage等いろいろ選択肢が増えたね

• URLパラメータ

  • 長さ制限あり

    • データが少ないとき選択肢となる

  • URLが変わるとブックマーク時に問題となる

    • 2Cのサイトで使用することへの反対意見

• hiddenフィールド

  • <input type="hidden" />なヤツ
  • 表示されないだけで、ソースを覗けば見えることに留意する

  • valueにはシリアライズしたセッション情報を入れる

    • XMLとか

• Cookie

  • 本書執筆当時は議論の的だったらしい
  • サーバとのreq/resのやりとりに自動的に乗る
  • 大きさに制限あり

  • エンドユーザに無効化されるおそれあり

    • もはやレアケース
    • 社内向けアプリケーションなら問題ない

  • 他の方法同様、セキュアでない

    • 【補】今ではHTTPSでsecure属性とかありますね

      • 通信経路が暗号化されているときだけCookie送信

  • ドメイン名別

    • 別ドメインに持ち出せない

  • Cookieの有効判定を行える環境もある

    • 無効化されていたらURLパラメータにフォールバックできる

      • セッションデータは少量であること

When to Use It

• 全セッション情報をClient Session Stateで持てば、Serverをステートレスにできる

  • クラスタリング、フェールオーバーとの相性良し
  • クライアントが落ちたらセッション情報は失われる

• セッションデータが大量だと問題噴出

  • どこにデータ置くの

    • 【補】今ではLocalStorage等あるね
  • req/resのたびに生じる転送コスト

• セキュリティ問題

  • Clientにセッションデータを置くということは、次のリスクにさらされるということ

    • 見られる
    • 改ざんされる

  • 暗号化しない限り防げない

    • リクエストのたびに暗号化/復号するのはパフォーマンス上の負荷になる

  • 暗号化しない場合、送り出したデータが同じまま返ってくるとは思うな

    • 再バリデーションしろ
• 大なり小なり必ず使う(前述どおり)
• セッションID値のみ持つ程度なら、負荷の問題は生じない

• セキュリティの問題は依然残る

  • セッションハイジャック

    • わるいユーザは、クライアント側で保持しているセッションIDを書き換えて、他人のセッションに悪さをしようとするかもしれない

    • セッションIDは予測困難にせよ

      • 乱数
      • 乱数でないなら、ハッシュ関数を通す

英語

• pry

  • のぞく、ほじくる