「欧州議会がcookie禁止法案を来週採決」記事へのコメント

Cookieなしでセッションの維持は・・・

[atrib (5512)]

Webアプリケーションを業務で開発している者なのですが、セッションを維持するのにCookieを使ってはいけない、と言われると非常に困りますね。Cookie禁止が設定されている場合を想定してURL Rewritingも使用できるようにはしてあるんですけど、REFERERで漏れる可能性があるし。

クロスサイトスクリプティングって設計をきちんとすれば防げるという認識をしているのですが、間違っているでしょうか？Cookieの問題点はクロスサイト～だけじゃないとは思いますが、無いと困るんですよね。

セッション

Re:Cookieなしでセッションの維持は・・・

[MLC (6565)]

　あまり良い方法ではないかもしれませんが、FORMのINPUTタグにセッションIDとセッションの状態を持たせています。(もちろんhiddenで)

　トップページのユーザーログインに成功した次のページからは、ログアウトまで全てFORMです。(^ ^;

　LANならまだ良いのですが、インターネットに出す場合はhttpsでないと怖いなあ、とは思います。

--
　 --- Melloques Les Covdrasey ---

Re:Cookieなしでセッションの維持は・・・

[G7 (3009)]

>FORMのINPUTタグにセッションIDとセッションの状態を持た
>せています。(もちろんhiddenで)

ええと。それって、

  * 全てがSubmitボタンになっちゃって、文字列をClickしたりすることは無くなる。
  * MethodはPOSTにしとかないとSessionIDが見えちゃう(=ユーザーにURLを記録され得る)と困るんで
      GETとかは使わない。
  * Inputタグは必ず「どれか1つの」FORMに従属するから、
      1つの入力欄を複数のSubmit先URLに関連付けることが出来ない。
      場合によっては"同じ"入力項目を複数個所で表示(入力を期待)しないとならない。

って感じになるんでしたっけ？

なんか色々と面倒な雰囲気(^^;;;

余談：
IEが表示するSubmitボタンは、WindowsでいうWindowなのかな？
だとしたら、多数出したらWin9x系では動かない、とか(笑)

Re:Cookieなしでセッションの維持は・・・

[MLC (6565)]

＞* 全てがSubmitボタンになっちゃって、文字列をClickしたりすることは無くなる。

　これは、「Aタグでリンクすると、GETになっちゃうのでPOSTできない」って意味ですよね。

　J(ava)Scriptを使わないという条件ですと、そうなります。(たぶん)

　で、私はそうしてます。(;_;)

＞* MethodはPOSTにしとかないとSessionIDが見えちゃう(=ユーザーにURLを記録され得る)と困るんでGETとかは使わない。

　はい。使いません。

　サーバーサイドで、GETかPOSTかをチェックして、GETの場合はエラーページを表示してます。

＞* Inputタグは必ず「どれか1つの」FORMに従属するから、1つの入力欄を複数のSubmit先URLに関連付けることが出来ない。
場合によっては"同じ"入力項目を複数個所で表示(入力を期待)しないとならない。

　これも、J(ava)Scriptを使わないという条件ですと、(たぶん)そうなります。なるべく、デザイン段階で工夫する必要があります。

　...この方法ですと、

• GETで表示する(静的な)ページは別ウィンドウ(かフレーム)で開く必要がある
• そもそも、セッション管理を自分で作りこむ必要がある

など、他にもヤなことが色々ありますよね。 ですから、ここまでするニーズがない限り、あまりお勧めはできません。(^^;;

　他に、何か良い方法はないもんですかね。

--
　 --- Melloques Les Covdrasey ---

Re:Cookieなしでセッションの維持は・・・

[G7 (3009)]

>＞* Inputタグは必ず「どれか1つの」FORMに従属するから、1つの入力欄を複数のSubmit先URLに関連
>＞付けることが出来ない。
>これも、J(ava)Scriptを使わないという条件ですと、(たぶん)そうなります。なるべく、デザイン段階
>で工夫する必要があります。

ふと思い出したんですが(つーか最初から思い出せよ俺)、
URLのアドレスの部分は変えられないけど、ボタンごとのパラメータ(正式名称覚えていません御免)を使って
次に表示すべき頁の内容を差し替える、って手は有りますね。

JavaServletだと、 引数に応じて RequestDispatcher.html#forward や同#includeあたりで
別頁(と呼ぶのが妥当かどうか疑問だが)に飛ばす/別頁を含める、っていう制御をやればいいのかな。
あるいは飛ばすまでもなくいちいち全然違う表示をレンダリングする手も有るでしょうけど。

1つのwwwアプリ(厳密な言い方じゃないが)を、
同一アドレス+SUBMITボタンのパラメータ＋forward/include、で全部まかなってしまう、
ってのは変なんでしょうか？

#あ。だんだんオフトピになってきたかも…

>・ そもそも、セッション管理を自分で作りこむ必要がある

まだ説明そこまで読んでないんですが、JavaServletって、
「セッション管理の仕掛」を自作(つまりPlugIn)できるんだったかなあ？
出来るといいなあ。

どうやると奇麗なのかなあ。うーみゅ。

Re:Cookieなしでセッションの維持は・・・

[MLC (6565)]

＞1つのwwwアプリ(厳密な言い方じゃないが)を、
＞同一アドレス+SUBMITボタンのパラメータ＋forward/include、
＞で全部まかなってしまう、
＞ってのは変なんでしょうか？

　“全部”まかなうかどうかは別にして、そういうのもアリではないかと思います。

　Java/Servletに限らず、サーバー・サイド・スクリプトの類なら、forward(Location:ヘッダで実現できる)機能やinclude(レスポンス用streamに当該ファイルをwriteすればできる)機能で、同様のwwwアプリが作れると思います。
　(手間は メチャメチャ かかりますけど・・・)

　自作セッション管理のメリットといえば、セッションの状態管理をサーバー側で自由に行える点でしょうか。

　もっとも、そのためには同一URLで、少なくとも
　　・同一セッションID(を示すINPUTタグ)
　　・セッション中の状態を表す値(を示す 以下略)
　　・指定されたイベントを識別する値(を示す 以下略)
くらいはリクエストヘッダとして受け取り、その後の状態管理を自力で書いたスクリプト(の先頭の方)で行う必要が有ります。

　この方法ですと、「戻る」ボタンや「次へ」ボタンに振り回されることも少なくなり、便利といえば便利ですが・・・。

　セッション切れ時のトランザクションの後始末等を自力で書いてると、こっちの血管が先に切れそうになります。いや、ほんと。

--
　 --- Melloques Les Covdrasey ---

Re:Cookieなしでセッションの維持は・・・

[shigezo (2455)]

＞IEが表示するSubmitボタンは、WindowsでいうWindowなのかな？
＞だとしたら、多数出したらWin9x系では動かない、とか(笑)

　Windowかどうかは解りませんがWin9X系でHTML FORMのプルダウン(SELECT)を
　いっぱい出すと途中からリソース不足で表示できなくなった事はありますね。

　カレンダーを表示して日毎にプルダウンを表示して数ヶ月分の更新を
　一度に行う様な仕様だったのを１ヶ月毎に変更した覚えがあります。
　変更後の方が使いやすくなったのは怪我の功名(?笑）

　重蔵。