セッションの実現方法について

Question

セッションの実現方法についての質問です。

「プロになるためのWeb技術入門」という本を参考にしております。

「セッションIDの受け渡し方には選択肢があります。CookieによるセッションIDの受け渡しはセッションIDが外部に漏れる可能性が低く、安全なのですが、ブラウザのセキュリティの設定によってはCookieの受け入れを拒否されることがあり、その場合はセッションを実現させることができません。
代替手段としては、GETリクエストのパラメータが考えられます。PHPではCookieが利用できない場合、「PHPSESSID」というパラメータ名でリクエストのURLにセッションIDが含められるようにformタグが自動的に書き換えられ、サブミット時にGETパラメータとしてセッションIDが渡されるようにしています。このような手法はURLリライティングと呼ばれています。
同様にTomcatでも「jsessionid」というパラメータがGETリクエストに付加されます。
Tomcatでは初回アクセス時にCookieとURLリライティングを併用してセッションIDをブラウザに送ります。そして、ブラウザから次に送られるリクエストの内容から、Cookieが利用出来るならばCookieのみを、そうでないならば、URLリライティングのみを使用するよう判断します。」

CookieによるセッションIDの受け渡しは理解しているのですが、URLリライティングによるセッションIDの受け渡しがイマイチわかりません。
まず、上の文章の前半で登場するPHPでのURLリライティングについてですが、Cookieが使えないならば、ブラウザ側はどのようにしてセッションIDを知るのでしょうか？
どうにかしてブラウザ側がセッションIDを知ることができれば、あとはURLリライティングによりセッションを実現することができるのはわかるのですが。

「TomcatではCookieとURLリライティングを併用してセッションIDをブラウザへ送ります。」とありますが、ブラウザに対して、URLリライティングを使って、セッションIDを送るというのが理解できません。と言いますのも、HTTPレスポンスを見ますと、そのようなURLを記述した部分は見つけられないからです。
これは一体どのような意味なのでしょうか？

以上、2点ですが、回答お願い致します。

Answer 1

当該書籍にGETとPOST、HTTPがステートレスであるという点についてなど解説があったかと思いますので、そちらを読むなり、実際にPHPで何かを作ってみると理解しやすいかと思います。が、以下で一応説明してみます。

前提のGETリクエストについて

まず、ブラウザ上でhttps://www.google.co.jp/search?q=hogehoge&ie=UTF-8とかを開くと、Googleにて「hogehoge」キーワードでutf-8エンコードのページが開きます。
上記のようなURLによるリクエスト（GET）を行うと、サーバー側（Google）は、qというキーの「hogehoge」というデータと、ieというキーの「UTF-8」というデータを受け取ることが出来ます。これがGETリクエストによる値の受け渡しです。

しかし、HTTPはステートレスですので、同じGoogleサーバーにあるはずの検索結果の次のページをそのまま開こうとしても、次のページにqというキーの「hogehoge」という検索ワードは引き継がれません。そのため、Googleの「次へ」のボタンのURLを見ていただけば分かりますが、ちゃんと「?q=hogehoge」が入っています。

1つ目について

PHP（Tomcatも仕組み的には似ていますが）は、ブラウザからのリクエストに対して、指定されたPHPファイルのコードを実行して結果をレスポンスとして返します。
質問文の該当部分をそのまま読むと、当該PHPファイルの中に

<form action="hoge.php">
    <input type="submit" value="送信">
</form>

というものがもしあった場合、

<form action="hoge.php?PHPSESSID=hfufdh78237r091uhf87y8013">
    <input type="submit" value="送信">
</form>

的に書き換えた結果をレスポンスとして返してくるということかと思います。
<form></form>は、通常POST（or GET）でのリクエスト送信を行いますが、PHPSESSIDをキーに=以後の値をサーバーが受け取れるということです。
現在では、セッションハイジャックの危険がありますので、このような実装はダメです。

2つ目について

「ブラウザに対してセッションIDを送る」「URLリライティングを使ってセッションIDをブラウザに送る」が理解出来ないとのことなのですが、URLリライトの仕組みを見ていただいた方が早いと思います。（ →URLリライトと301リダイレクトの仕組み | Moz - SEOとインバウンドマーケティングの実践情報 | Web担当者Forum ）

大まかにいって、サーバーからブラウザに「そのURLこっちだよ」といい、ブラウザが「あ、そうなの？変えとくわ」という仕組みが存在し、その「こっちだよ」にセッションIDが付加されたものが渡されているということです。あとは、次のページに遷移するときに、そのセッションIDが付加されたままのURLで遷移すればよいということになります。

Comments

[退会済みユーザー]

1点目についてですが、ブラウザ側がセッションIDを知ることができれば、URLリライティングにより、以後の通信は行うことはできると思うのですが、その初めはどのようになっているのか、というのが私の質問です。
と言いますのも、この本の説明によりますと、ブラウザ側はセッションIDをCookieによって知るわけです。
そして、この場合、ブラウザ側はCookieは使えないので、セッションIDを知ることはできないように思えるわけです。

二つ目についてですが、これは301リダイレクトのことですしょうか？

[amaranthine]

１点目につき、「その初め」について解説しました。おわかりにならないのであれば、私にはこれ以上の説明はできません。なお、その本は私の手元にもありますが「ブラウザ側はセッションIDをCookieによって知る」などとは書いていません。そもそもセッションIDはサーバーが生成するものですし、Cookieはサーバーから送られた情報を元にブラウザが生成するものです。

2つ目について、URLリライトという仕組みがあり、それは301リダイレクトとは違います。読んでいただいて分からないのであれば、私からはこれ以上の説明はできません。

[退会済みユーザー]

お返事ありがとうございます。
一点目についてですが、115ページに「Webアプリケーションでのログインのように、セッションを開始する時にはWebサーバ側が新しいセッションIDを発行します。発行したセッションIDは、HTTPレスポンスのCookieへ格納してクライアントへ渡します。」と明記されています。
これはより詳細にいうと、HTTPレスポンスのSet-CookieヘッダでセッションIDをブラウザ側に告知しているわけですが、私はこれを「Cookieによって、セッションIDを知る」と表現しているのです。
言葉足らずで申し訳ないですが。

182ページに「PHPではCookieが利用できない場合、「PHPSESSID」というパラメータ名でリクエストのURLにセッションIDが含められるようにformタグが自動的に書き換えられ、サブミット時にGETパラメータとしてセッションIDが渡されるようにしています。このような手法はURLリライティングと呼ばれています。」とあり、そのプロセスの「初め」を説明したとのことですが、そうすると、この本の例ですと、ログインの後にセッションIDが発行され、その情報がサーバー側に保持されるようになりますが、「ログインの前に」セッションIDがサーバ側で生成される、ということになるのでしょうか？
また、ブラウザ側がCookieを使えない、という情報は最初ないと思いますので、初めにブラウザにPHPスクリプトにより生成されたhtmlを送り込んだ時にはすでにformタグが書き換えられており、以後はCookieが使えるなら、Cookieを、Cookieが使えないなら、GETパラメータでセッションIDを渡すということになるのでしょうか？

二点目について、「サーバーからブラウザに「そのURLこっちだよ」といい、ブラウザが「あ、そうなの？変えとくわ」という仕組み」はURLリライトのことなのでしょうか？
と言いますのも、教えていただいたサイトや他のサイトを参考にしますと、URLリライトはサーバ側で行われる処理で、クライアント側からすると、表示されるURLは変わらないのですよね？

質問が多く恐縮ですが、教えていただけると幸いです。

[amaranthine]

1点目につき、「この本の説明によりますと、ブラウザ側はセッションIDをCookieによって知るわけです。」とおっしゃられていましたが、同じページのその前に「セッションIDは、（略）「Cookieを利用して状態を保持する」で説明したCookieを利用してやりとりすることが出来ます」と書いてあります。別にCookieを利用しないといけないとは書いてません。ブラウザ側はセッションIDをCookieによって「も」知ることが出来ると書いてあるに過ぎません。

182ページにつき、セッションIDの発行タイミングはコードにより任意なので当初からされ得ます(PHPだとsession_start()関数実行時、通常いつもコードの最初に実行。Struts1だとreq.getSession()実行時)。
また、当初リクエスト時からCookieがいけるか否かの情報は送信されてます(httpリクエストのcookie項目があるか無いか)。ログインの前後は関係ありません。

二点目について、表示と内部的に保持される値は違い、後者がブラウザに保持されます。

いずれにせよURLリライトによるセッション管理はセキュリティの関係上、現在は基本的に使われていません。

質問が、ブラウザ/HTTPプロトコル/アプリケーションサーバーの仕様にまで及んでいますが、めんどくさいので以後私からは回答いたしません。質問を分けるなり、実際に作ってデバッグしてみるなり、Apacheのソースをみるなり、RFCドキュメントを参照するなりしてご確認ください。

セッション管理を今から「実現する」という観点からは、そこを確認する必要は無いかと思いますが。

[退会済みユーザー]

回答ありがとうございました。