質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

88.03%

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

解決済

回答 1

投稿

  • 評価
  • クリップ 0
  • VIEW 3,385
退会済みユーザー

退会済みユーザー

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

「プロになるための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点ですが、回答お願い致します。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 過去に投稿した質問と同じ内容の質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 1

checkベストアンサー

0

当該書籍に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で遷移すればよいということになります。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/09/25 10:19

    お返事ありがとうございます。
    一点目についてですが、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は変わらないのですよね?

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

    キャンセル

  • 2016/09/25 11:49

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

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


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

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

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

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

    キャンセル

  • 2016/09/25 13:41

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

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 88.03%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る