通信が発生するということは、
DBとのセッションを毎回確立する必要があります。
(Webサーバーの機能でDBセッションを保持することも可能ですが)

サイトへの同時接続数にもよると思いますが、
すべてのページでDBにアクセスするのは、コストがかかり過ぎると思います。
インフラに投資できるプロジェクトであればさほど気にすることでもないかもしれませんが。

どの程度の規模だとどのぐらいの規模なのでしょうか？

ユーザ情報を取得するにはDBにアクセスしなければなりませんし、ログイン処理があるのであれば、ログイン済チェックを毎ページ行わなければなりません。

規模が小さいと気になりませんが、ある程度大きくなってくると影響が出てきます。

—-
auとsoftbankはcookieを利用するということですが、3GC端末であれど、一部機種で利用できなかったりします。

突き詰めて考えると、古い機種やイレギュラーな機種などの対応などを含めて、３キャリアともURLにsessionidを乗せるのが上策かと思います。

セキュリティ面では以下の様にして高めることは可能です。

・IP制限を行う
・セッション内のUIDと、アクセスしているUIDでの認証
・UIDが取得できない場合は「ごめんなさい」

携帯の場合、ブラウザバックが当たり前ですので、session_regenerate_id()は常用しておりません。

一意なユーザーIDが取れるなら、外部にセッションを出す必要はありません。

拝見させていただきました。
大変参考になるコメントありがとうございます。

auの場合が大変そうですね。
クッキーベースをやめることで対応はできそうですが。。。

結局セッションIDをURLをつけるのってどうなの？という話に回帰してしまいますね。

au,SoftBankでCookieを使用したセッションをする場合に
SSLをまたぐと問題が出てきます。
根本的な解決方法は思い浮かばないのですが。。

http://d.hatena.ne.jp/maru_cc/20080512/au_ssl_cookie
http://d.hatena.ne.jp/maru_cc/20080512/mobile_ssl_cookie

いつもコメントありがとうございます。そしてご返信が遅れて申し訳ありません。
なるほど納得です。私の視点はシステム屋としてのもので、一般の方にとっては意識せず友達に教えてしまうものなのですね。そうかもしれません。
metaタグの件もありがとうございます。勉強になります。
この件もそうですが、キャリア間で規格を統一して欲しいですね。
ドコモがクッキーに対応してくれれば、これらの問題は万事解決なんですが。

> メールでURLを他人に送信する際…
なぜそんなことをするのか？
サイトへのログイン認証時のURLなんてだれも他人に教えないでしょう？
って思っていましたが、メールでURLを送信と言うのは
いわゆる「お友達におしえる」っていう行為なんですね。

つまりユーザの多く（大多数？）はセッション入りのURLだろうと何だろうと
面白いと感じたサイトのURLはすぐ、そのままメールするようですね。
それが認証通過後のサイトコンテンツページのURLならば、なおさら
危機感を感じる事はないのでしょう。
（若年女性中心のサイトを運営している為かも知れませんが、最近↑を
教えてくれるような事例に出会いました。）

私が知る範囲ですが、現状ではお小遣いポイントサイトやHPスペース
などでは一律URLにセッションIDを付加して、IDを変化させると言う事は
していないと思います。
まぁジャンルがジャンルだけにそれで良いのかもしれませんが。

話を戻して、「アドレスを他人に教える」場合ですが、DoCoMoだと
ブラウザ側の操作でそのようなメールが簡単に作成できるのですね。
（だからそれが問題になるのでしょうが）
auだとブックマーク先のURLをmetaタグで指定できるのですが、
そういったことが可能であればなぁと思いました。

度々コメントありがとうございます。

> メールでURLを他人に送信する際に、
> 一度アクセスすると思います。
> その後、他人がそのURLでアクセスしてもドコモの場合は、
> 端末IDなどで本人かどうか調べることはできないから、
> 素通りできてしまいます。

もしおっしゃることを正しく理解していなかったらすいません。

メールで他人にURLを送ったとしても、それは既にsession_regenerate_id()が動いた後のURL（古いセッションIDが記述されたURL）のため、送られた側の人はセッションを引き継げないと思ったのです。
PCのようにHTMLソースを見て、リンク等から新しいセッションIDを知ることができ、それを他人にメール出来ていれば別ですが。

どちらにしても、セッション情報を含んだアドレスを他人に教えるというその行為自体が一番の問題なのかもしれないですけどね。

＞こちらはあり得ません。
＞なぜなら本人が一度アクセスしないと新しいセッションIDがわからないた＞め、他人に教えることができないからです。

メールでURLを他人に送信する際に、一度アクセスすると思います。
その後、他人がそのURLでアクセスしてもドコモの場合は、端末IDなどで本人かどうか調べることはできないから、素通りできてしまいます。
その時、PHP内部でsession_regenerate_id()が作動してしまい、セッションIDが変わります。
他人がアクセスした後、本人がアクセスしようとしたら、セッションIDが変わっているため、さきほどのURLでは認証失敗ということになるのではないでしょうか？
間違っていたらすいません。

3/31が待ち遠しいですね！

コメントありがとうございます。
セッション入りのURLを他人に教えてしまった場合、確かにセキュリティ上の問題がありますね。
ドコモ端末では、session_regenerate_idを使わない限り、これは避けられないと思います。
（他人に教えた時点で自己責任という面もありますが。。。）

ただ、

> 他人にメールでURLを送信後、本人が一度もそのサイトに
> アクセスせずに、URLを受信した他人がアクセスしてしまった
> 場合、session_regenerate_id()されるので、
> 本人はアクセスできなくなるのではないでしょうか。

こちらはあり得ません。
なぜなら本人が一度アクセスしないと新しいセッションIDがわからないため、他人に教えることができないからです。

> mixiなどのサイトではどういう処理で簡単ログインさせているのでしょうか。

mixiで確認してみたところ、やはりURLの後ろにセッションIDが付加されているようです。
ですが、session_regenerate_id()は使用していないようで、アクセス毎にセッションIDが変わることはないようです。

ただ、3/31からドコモでもiモードIDが取れるようになるようですので、こちらを使うことで、この辺りの問題を一気に解消できそうな感じです。

他人にメールでURLを送信後、本人が一度もそのサイトにアクセスせずに、URLを受信した他人がアクセスしてしまった場合、session_regenerate_id()されるので、本人はアクセスできなくなるのではないでしょうか。（再びセッションを作成する処理をしない限り->端末IDを送信する必要がある）
またその間になんらかの操作が行われた場合、なりすましも可能です。

mixiなどのサイトではどういう処理で簡単ログインさせているのでしょうか。
docomoの実機がないので検証できません。AU＆softbankではURLにsidが埋め込まれていないので、cookieを使っているようです。

コメントありがとうございます。
大変わかりやすい説明で参考になりました。

これで一定の結論が出た気がします。
3キャリア実機で動作を確認した後、適切と思われる形に記事を修正・追記しようと思います。
もしよろしければ、後ほどまたご確認をお願いいたします。
ありがとうございました。

いくつか気になったので…

>設定が有効になると、リンクの後ろに自動でセッションIDが付加され、セッション変数が引き継げるようになります。
設定次第でしょうが、クッキーが使えない環境の時に限り…とできます。
その場合auやSBでは特に何も気にせずPCと同様session使えます。
（URLにSIDが透過的に付加されません。）

>リンク先のページにRefererが漏れてしまったり
URLに埋め込みが必要なのは、実際i-modeのみでしょう。
それでいて、i-modeはリファラーを吐きません。
結局、上記のような状況にはならないのでは？？？

それでも気になるなら、画面遷移にaタグは全て使わず、postにすればよい。
この場合もPHPが勝手にhidden要素を付け加えてくれるから、URLはキレイ
なままsessionは保たれます。

たしかにセッションハイジャックって行われたら恐ろしい事でしょうが、クッキーならOKでURLに埋め込むとダメっていうのは、携帯の事情を知らなすぎるのではないでしょうか？
（>指摘された方）

auとSoftBankの場合は、ほぼCookieが使えますし、端末IDの取得も容易なため、記事内の対応策1, 2の方法を使えば大丈夫そうですね。

問題はDoCoMoの場合ですが、こちらは扱う情報の重要度によって、利便性とセキュリティのトレードオフになってしまうのかな、と思っています。

対策案として次のようなものを考えてみました。

(1) 気にせずsession_regenerate_id()を使う。通信エラーが出た場合はやりなおしてもらう。（1番セキュア？）
(2) 毎ページ端末IDを送信してもらう（同じくセキュアだが毎回ダイアログが出るため現実的ではない）
(3) セッションの時間を短くして多少安全度を上げる（気休め程度の効果？）
(4) セッションにユーザエージェントを持ち、アクセス毎に照合する（IPアドレス制限との併用でそこそこの効果？リファラが漏れている場合は、同時にUAも漏れているため完璧ではない。）

重要な個人情報を扱う場合は、多少利便性を低下させても(1)の方式を取らざるを得ないのかなと思っています。いかがでしょうか？

せっかくの機会ですので、ここで最良と思われる方法を見つけ出したいと思っています。
ノウハウをご存知の方がいましたらぜひコメントをお願いします。

※記事内にも注意書きを追加しました

またAUのproxyで同一リクエストを二回出す場合がなぜかあります。AUのproxyは要注意です。