がるの健忘録 このページをアンテナに追加 RSSフィード

2013-06-14

[][][]認証、どうしようかねぇ?

自作しているBtoCのゲームサイトのauthentication、のお話し。

前提としては「スマフォガラケー用のゲームサイト」。現在絶賛作成中*1


タブレットとPCはどうすっかねぇ、と。

排除はしない。デザイン的に想定するかしないか。

ガラケー以外は「レスポンシブWebデザイン」とかでいい感じにしてみるかしらん。

まぁ「画面サイズ」くらいしか見ないんだろうけどさ。


センス? それなに? 美味しい?


閑話休題


んでまぁ上述を作るのに当然ながら「認証」が必要になるわけですます。

一応セキュリティ意識して実装するけどさ、それでもやっぱり「馬の骨とも分からんところにパスワード入れられっかい!」という可能性も否定は出来ないわけで。

もわもわと考えてる実装を…どうしようかなぁ、っと。



こんな感じ?

これくらい豊富だと、登録もそんなに困らないかなぁ?って思ってるんだけど。

一端「idとパスワード」実装して、早めに「メアド」の実装。OAuthは後回しって思ってるんだけど…どうかなぁ?


ご意見求む!!w

*1:停滞中とか言うな(号泣)

2009-06-03

[][][]心の底から心おきなく、memo(笑

1.

data_clumpに「検索系」を混ぜ込むイメージの草案

  // XXX 1
  $obj = new clump;
  $obj->set_from_cgi($req);
  $obj->set_order_by(項目);
  $ar = $obj->get_list( order by ? ); // 設定された項目でselect pkのListをげと

  // XXX 2
  $obj = new clump;
  get_pk
  get_table_name
  $ar = $obj->get_where(); // where句の取得
page_controll_limit.inc

  // XXX 3
  $obj = new clump;
  $obj->set_from_cgi($req);
  $obj->set_order_by(項目);
  $obj->set_page_num(n);
  $obj->set_page_all();
  $ar = $obj->get_list(); // 設定された項目でselect pkのListをげと
  $ar = $obj->get_object_list(); // 設定された項目でselect pkのListをげと

に。

下記の2行はありがちなので、まとめて1メソッドにする構想。

…つくる? お便利系だが。clumpあればいらんのだよねぇ。

  // 名を取得
  $name = $req->find('name');
  $conv->monoDic('name', $name);

さん。

携帯認証系
セッションIDをURIに埋め込まざるを得ない場合。
output_add_rewrite_var
なんだけど…httpsで切れるからなぁ。作るか?


IPチェック
$n = sprintf(’%u’, ip2long($ip));
ではあるんだけど………
ハッシュテーブル独自に持ってやる? : 実装面倒
いっそhash配列?:メモリどれくらい食う?

よん。キャッシュさせない系の話

Cache-Control: private, no-store, no-cache, must-revalidat

調査せな。


ご。

検証して、サニタイズクラスに追加実装すっかなぁ

SELECT COUNT(*) FROM USERS WHERE ID='' or 1=1--' AND PASSWORD='' or 1=1--'
標準SQLでは「--」以下はコメント(MySQLは「#」がコメント記号)だから、where句は常に真となり、パスワードを知らなくてもログインができてしまうというものだ。

ろく。

メモリ測定

memory_get_usage()

いぢょ ノ

2009-05-25

[][]authenticationとauthorizationの設定について

「設定ファイルに設定を書く」か「modelのどこか(initializeあたり)に設定を書くか」で悩んだ。


結果的に

・設定ファイルには「ユーザが触ってもある程度よいもの」を書きたいし、認証周辺はぶっちゃけ触らせたくない

・厳密には設定ファイルのほうがパースにcostがかかるのが、微妙にいや

の2つの観点から、一端「modelのinitializeあたり」に設定を書くように変更。


なにかもうちょっと積極的な理由があればいつでも話をひっくり返しますが B-p

2009-05-24

[][]session_dataクラスに関する覚え書き

一瞬、こんな事を考えた。


valueをシリアライズする事で、オブジェクト、配列を含む様々なデータを保持できるようにする。


良いアイデアに感じたのだが。冷静に考えると、セッションデータ周りは、ただでさえ「重たい」ものである。

のに対して、不必要かもしれないstringやnumericに対してまで、どんだけ軽微だとしても、serialize & unserializeが走るのは如何なものかと。

どうしても型を保存したきゃ「自力で必要なvalueに対してだけやって」という心を込めて、あえて実装しない事にする。

2009-05-23

[][][]サンプルサイト作る

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なので「必要になったものを必要になってから作る」んだけど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。