gallu’s blog

エンジニアでゲーマーで講師で占い師なおいちゃんのブログです。

サンプルサイト作る

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
 *DoCoMoCookie非対応端末なら契約者固有ID
 *DoCoMoCookie非対応端末なら契約者固有ID+User-agent
 *携帯は、ID/Password と 契約者固有IDから、ユーザ任意
あたりかなぁとりあえず。どうせclass入れ替えれば「しゅ〜りょ〜」なFactoryなので「必要になったものを必要になってから作る」んだけどw
厳密には「セッションIDのやり取り方法」もからむんだけど、ここでは省略。
CookieかGET引数か契約者固有IDちょく使いか、の3種類。Postで引き回すのは…やりたいけど厳しいだろうなぁと予想。必要あれば作るけどさ。


ーー
base_model内の動きを含む「認証系クラス群」としては…


auth_base:認証系全体共通
authentication:「誰かを特定する」メイン。Factoryで必要なインスタンスをゲトって処理
authorization:「セッションを繋ぎ続ける」人。Factoryで以下略。
authentication_factory:
authorization_factory:
authentication_base:「誰かを特定する」系基底クラス
authorization_base:「セッションを繋ぎ続ける」系基底クラス


こんな感じかなぁ。
具体的な「利用方法」はサンプルプログラムを乞うご期待w

ーー
で…どれを使うかは…configかなぁ? modelのinitializeメソッドかなぁ?
わずかではあろうけど。パースのコストを考えると…業務系基底クラスのinitializeメソッドが妥当な気がしてる。


ーー
などと、覚え書き的にmemo。