Session tracking through HTTP cookies is the most used session tracking
mechanism and is required to be supported by all servlet containers.
The container sends a cookie to the client. The client will then return the
cookie on each subsequent request to the server, unambiguously associating the
request with a session. The name of the session tracking cookie must be
JSESSIONID.
「2つのクッキーを使い分ける」ってのがねー (スコア:2, 興味深い)
というのも，JavaのServletでセッション管理に使われるCookieの文字列は，Servlet APIの仕様 [jcp.org]で， というぐあいに，「JSESSIONID」という文字列に固定されちゃってるんだよね。WebアプリやWebコンテナの都合で勝手に変えるわけにはいかない。
といって，方法 Aの「すべてのページを https://...にする」というのも，全部のサイトで実現できるわけではないし。
さて，どうしたもんだろ？
Re:「2つのクッキーを使い分ける」ってのがねー (スコア:1, 参考になる)
暴言かましてよかですか? (スコア:2, 参考になる)
>つまり，コンテナが管理しているセッションIDとは別に，セッションID を管理してあげればよいのです。
面 倒 臭 ぇ
…いや、まあ、その、あなた様の意見は正論です、その通りです。返す言葉もございません。
しかし、それじゃあなんの為にセッション関連のインターフェイスが提供されて実装知らなくても扱えるようになってんだ、と。
成る程、こうしてセキュリティホールが出来上がるのか。
Re:暴言かましてよかですか? (スコア:0)
そのとおりだと思いますよ。面倒くさいですし，いちいち実装していたらバグの温床になります。
でも，一度実装しちゃえばアプリケーションごとで変わるものでもないですよね。
フレームワークとして実装するなり，既存のフレームワークを使用するなりが筋でしょう。
Re:暴言かましてよかですか? (スコア:0)
いや、むちゃくちゃな納期でデスマーチになってたり、キッチリやっても評
Re:暴言かましてよかですか? (スコア:1)
ブラックボックスというか、「フレームワーク」と呼ぶものなんでしょうね。
問題は、そのフレームワークの「ホットスポット(改造予定個所)」が
適切に用意されているかどうか、なんですが…
たしかにJavaServletのあのcookieを初めて見たときには、
ちょっと首を傾げたもんでした。
「なんで変更するメソッドが無いんだろう？」って。
まあ、そのうち改善されてくれることを期待します。
Sevlet APIも、時と共に少しづつバージョンが上がっているわけですから。
少なくとも全くの無神経ってことは無いようですよ。
たしか以前にも、ヨソのセッションに属するObjectをアクセスできちゃうメソッドが廃止になった
という改良が有ったような記憶が。
＃そもそもそんなメソッドが最初から有るのが変だ、とも言えるかもだが。
Re:暴言かましてよかですか? (スコア:0)
#未来永劫、今の実装だとだれが決めた?
つか、各ベンダにリクエストしようぜ。
Re:「2つのクッキーを使い分ける」ってのがねー (スコア:0)
少なくとも俺はいままでない。
Re:「2つのクッキーを使い分ける」ってのがねー (スコア:0)
全部がSSLだと、暗号・復号で(サーバもクライアントも)重くなるというのを嫌ってそうしているのだと思います。確かに商品画像まで暗号化して送るこたーない。
Re:「2つのクッキーを使い分ける」ってのがねー (スコア:0)
> 少なくとも俺はいままでない。
それやらかしてるところは見たことがある。
wwwブラウザに怒られるのは言わずもがな。
Re:「2つのクッキーを使い分ける」ってのがねー (スコア:0, 余計なもの)
ネ タ が つ ま ら な い か ら 荒 ら し 認 定 さ れ る ん だ
せめて隣りの奴が笑ってから投稿せぇ