アカウント名:
パスワード:
方法 B： 2つのクッキーを使い分ける サイトの設計上、http://... の画面と https://... の画面をまたがってセッション管理を行う必要がある場合は、2つのクッキーを発行し、一方を secure 属性付きとし、もう一方を secure 属性なしとします。https://... の画面ではセッション管理に前者のクッキーを使用し、 https://... の画面では後者のクッキーを使うようにします。 このとき、暗号化で保護が必要な画面（https:// を使うことにした画面）に対して、http:// でアクセスされても情報を表示しないように作る必要があります。そうしないと、攻撃者は、盗聴で盗み出し
そのとおりだと思いますよ。面倒くさいですし，いちいち実装していたらバグの温床になります。
でも，一度実装しちゃえばアプリケーションごとで変わるものでもないですよね。 フレームワークとして実装するなり，既存のフレームワークを使用するなりが筋でしょう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
計算機科学者とは、壊れていないものを修理する人々のことである
「2つのクッキーを使い分ける」ってのがねー (スコア:2, 興味深い)
Re:「2つのクッキーを使い分ける」ってのがねー (スコア:1, 参考になる)
暴言かましてよかですか? (スコア:2, 参考になる)
>つまり，コンテナが管理しているセッションIDとは別に，セッションID を管理してあげればよいのです。
面 倒 臭 ぇ
…いや、まあ、その、あなた様の意見は正論です、その通りです。返す言葉もございません。
しかし、それじゃあなんの為にセッション関連のインターフェイスが提供されて実装知らなくても扱えるようになってんだ、と。
成る程、こうしてセキュリティホールが出来上がるのか。
Re:暴言かましてよかですか? (スコア:0)
そのとおりだと思いますよ。面倒くさいですし，いちいち実装していたらバグの温床になります。
でも，一度実装しちゃえばアプリケーションごとで変わるものでもないですよね。
フレームワークとして実装するなり，既存のフレームワークを使用するなりが筋でしょう。
Re:暴言かましてよかですか? (スコア:0)
いや、むちゃくちゃな納期でデスマーチになってたり、キッチリやっても評
Re:暴言かましてよかですか? (スコア:1)
ブラックボックスというか、「フレームワーク」と呼ぶものなんでしょうね。
問題は、そのフレームワークの「ホットスポット(改造予定個所)」が
適切に用意されているかどうか、なんですが…
たしかにJavaServletのあのcookieを初めて見たときには、
ちょっと首を傾げたもんでした。
「なんで変更するメソッドが無いんだろう？」って。
まあ、そのうち改善されてくれることを期待します。
Sevlet APIも、時と共に少しづつバージョンが上がっているわけですから。
少なくとも全くの無神経ってことは無いようですよ。
たしか以前にも、ヨソのセッションに属するObjectをアクセスできちゃうメソッドが廃止になった
という改良が有ったような記憶が。
＃そもそもそんなメソッドが最初から有るのが変だ、とも言えるかもだが。
Re:暴言かましてよかですか? (スコア:0)
#未来永劫、今の実装だとだれが決めた?
つか、各ベンダにリクエストしようぜ。