model実装の変更っつか追加予定( http://d.hatena.ne.jp/gallu/20090513/p2 )に絡む話。
っつか「作ってテスト」用兼ねて(笑
作るのは下記の予定。
フロントとして
・非認証index page(non_authed_static)：index
・login機構及び認証後Top Page：login top
・認証/非認証どちらでもOK Page：ambiguous_auth_page
・認証 静的Page(authed_static)：auth_page
・入力 -> 確認 -> 完了 line：sample_*
・編集 -> 確認 -> 完了 line：sample_*
・(会員登録：空メール方式)
フロントエンドとして
・ログイン機構一式：
・検索 -> 一覧 -> detail -> 編集/削除：sample_*
・入力 -> 確認 -> 完了 line：sample_*
ーー
これを…特にフロントは、認証パターン毎に別々に作ろうかなぁ、と。いやその場合多分、残りは
フロントとして
・非認証index page(non_authed_static)：index
・login機構及び認証後Top Page：login top
だけでいいんだろうけど。
ーー
認証パターンとしては…とりあえず…
・ID/Password
・契約者固有ID ＆ PCは拒絶
・PCならID/Password
＊携帯なら契約者固有ID
＊携帯なら契約者固有ID＋User-agent
＊DoCoMoなら契約者固有ID
＊DoCoMoなら契約者固有ID＋User-agent
＊DoCoMoでCookie非対応端末なら契約者固有ID
＊DoCoMoでCookie非対応端末なら契約者固有ID＋User-agent
＊携帯は、ID/Password と 契約者固有IDから、ユーザ任意
あたりかなぁとりあえず。どうせclass入れ替えれば「しゅ〜りょ〜」なFactoryなので「必要になったものを必要になってから作る」んだけどｗ
厳密には「セッションIDのやり取り方法」もからむんだけど、ここでは省略。
CookieかGET引数か契約者固有IDちょく使いか、の３種類。Postで引き回すのは…やりたいけど厳しいだろうなぁと予想。必要あれば作るけどさ。
ーー
base_model内の動きを含む「認証系クラス群」としては…
auth_base：認証系全体共通
authentication：「誰かを特定する」メイン。Factoryで必要なインスタンスをゲトって処理
authorization：「セッションを繋ぎ続ける」人。Factoryで以下略。
authentication_factory：
authorization_factory：
authentication_base：「誰かを特定する」系基底クラス
authorization_base：「セッションを繋ぎ続ける」系基底クラス
こんな感じかなぁ。
具体的な「利用方法」はサンプルプログラムを乞うご期待ｗ
ーー
で…どれを使うかは…configかなぁ？ modelのinitializeメソッドかなぁ？
わずかではあろうけど。パースのコストを考えると…業務系基底クラスのinitializeメソッドが妥当な気がしてる。
ーー
などと、覚え書き的にmemo。
