2009-05-25

authenticationとauthorizationの設定について

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

結果的に
・設定ファイルには「ユーザが触ってもある程度よいもの」を書きたいし、認証周辺はぶっちゃけ触らせたくない
・厳密には設定ファイルのほうがパースにcostがかかるのが、微妙にいや
の２つの観点から、一端「modelのinitializeあたり」に設定を書くように変更。

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

2009-05-24

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

開発Blog MagicWeapon

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

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

良いアイデアに感じたのだが。冷静に考えると、セッションデータ周りは、ただでさえ「重たい」ものである。
のに対して、不必要かもしれないstringやnumericに対してまで、どんだけ軽微だとしても、serialize ＆ unserializeが走るのは如何なものかと。
どうしても型を保存したきゃ「自力で必要なvalueに対してだけやって」という心を込めて、あえて実装しない事にする。

2009-05-24

新しいサービス構築用memo

MySQL

create database でぇたべぇす名;
grant ALTER, CREATE, DELETE, DROP, INDEX, INSERT, LOCK TABLES, SELECT, UPDATE on でぇたべぇす名.* to ユーザ名@ホスト名 identified by 'ぱすわぁど';
flush privileges ;

ちなみに「ぱすわぁど作成」にはこちらが便利…とかって宣伝ｗ
http://www.gjmj.net/makepass.php

2009-05-23

サンプルサイト作る

開発Blog MagicWeapon memo

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。

2009-05-20

認証周り

携帯

携帯で如何に認証をするか、って話です。

えと…「当サイトではCookieが使えない端末でのご利用は出来ません」とか書けると楽なのですが…Cookieが使えないことで有名な、DoCoMoさんとかDoCoMoさんとかDoCoMoさんとかが…やっと対応したとはいえ、まだまだ世間様にそのマシンが行き渡るにはしばらく時間がかかるでしょう。
また「簡単ログインがイイ！！」ってユーザさんも多い事を考えると…まだまだ気が抜けません。

当然ながらこの手のことに「唯一解」なんて存在しないのですが。
存在しないなりに、いくつか想定のバリエーションくらいは考えておきたいものです…ってのが、このエントリーの趣旨です。

いち：
素直にIDとパスワードを使う。
DoCoMo以外はCookieで行けますし。DoCoMoも、最新機種はいけるみたいですし(機種名Listつくらんとなぁ)。
で、DoCoMoの「滅び行く、Cookie仕様不可な駄目機種」については…PHPであれば output_add_rewrite_var とかを用いるのが、やむを得ない現実解ですかねぇ？
ただ、セッション系のアタックにもの凄く気ぃ使わなきゃいけませんが。

に：
簡単ログインでIPをちゃんと絞る。
現状一番おおいパターンですが…「戻りが必要ないアタック」だと、IPパケット偽装すりゃアタック可能なんですよねぇ orz
重要なところだけでも「糅てて加えてぱすわぁど」とか、ギミックを設置してみたいもんです。

さん：
条件付きで「user-agentあたりの情報と併用」する。
つまり、認証を「契約者固有ID ＋ user-agent」とかにする。
んと…「総当たり攻撃」なら、これで要素数が増えるので、少しマシかなぁ、程度。決めうちに対しては全くの無力。
機種変については「機種変えたら一回メールで認証かけ直すから」とかいうギミックで対処、かなぁ。

よん：
いちとにをユーザに選ばせる。さんはお好みでトッピング可能。
便利と安全と「今夜のご注文は、ドッチ！」

もうちょっと…携帯で実際にアタックされている資料がそろうと対抗策が考えつくのですが(苦笑
とりあえず…こんな所から考察startかなぁ。

突っ込み大歓迎ｗ

2009-05-20

携帯なのかPCなのか

携帯

割合によくあるこの手の要求について…ちとまじめに掘りこんでみたいかなぁ、と。
要求の根幹は「アクセスしてきたのが携帯なのかPCなのかを知りたい」ってあたり。

で…「なんで」それを知りたいのか、について、概ね二種類が想定できるです。
・絵文字処理その他表示の問題
・契約者固有IDなどと偽装にまつわる問題

次に…前提条件として。
判定方法としては概ね「USER-AGENT」と「from IP」の２種類が考えられるのですが。

USER-AGENTは、キャリアが新しいなにがしかを作ってこないかぎり「新機種が出ようとも気にせずに使える」のですが、一方で偽装が容易です。

from IPは、比較的偽装が困難なのですが(無理な訳じゃないし、これによって成立しうるアタックも十分にある)、ある程度のガードが可能です。
ただ根本的に「キャリアからの情報が信用できない」というネックがありまして。
http://d.hatena.ne.jp/gallu/20081108/p3
http://d.hatena.ne.jp/m_norii/20081106/1225981496
http://d.hatena.ne.jp/gallu/20081111/p1
日々の運用コストも含めて、もの凄く真摯に考えなきゃいかん現実ってぇもんがあります。
ついでに…「どこでチェックを入れるか」も、色々と頭の痛いところです。
っつか、.htaccessは、個人的には「毎回ファイル読み込まれるなんて頭痛がする事されたくない」ので、httpd.confで真っ先に切る機能のひとつですし。
さりとて、PHPで毎回チェックするのも…そのあたりのコードのパースとかのコストを考えると、結構いやなもんです。
とは言っても「httpd.confを書き換える」ってのも個人的に抵抗感ありますし。
おいちゃん的には
・必要なキャリアさん各サイトについて定期的にチェック＆ mail
・httpd.conf内でIncludeで各キャリアについて別ファイルで管理＆必要なら書き換えてreload
が一番無難な落としどころ、ですかねぇ。…台数が増えると「手動でreload 」も相当にしんどいので。なにがしか考慮する必要がありますが。

んで。

まず、楽な「絵文字処理その他表示の問題」から。
これは「USER-AGENTに従って処理を振り分ける」で終了。
理由は簡単で。「偽装したら自分が見づらくなるだけ」なので、別に偽装について考慮をする必要性は原子の一欠片ほどもないので。
だとすると、判定としてはUSER-AGENTを用いるのが一番楽。手間がかかり倒すIPで判定せにゃならん理由などまったくありません。

問題は「契約者固有IDなどと偽装にまつわる問題」の場合。
実際私もやりますが。FireFoxあたり使うと、ブラウザレベルで簡単に偽装ができるんですよねいやまぁテストには便利なんですが。
とりあえず考え方としては二つ。
・契約者固有IDなんて使わない：よりコレクト
・デメリットを踏まえた上で、日々の運用までをちゃんと設計した上でIPアドレスによるチェックをする：やむを得ない現実解？
このどちらか、でしょうか。多分。

前者をチョイスしたいのですが…DoCoMoさんとかDoCoMoさんとかDoCoMoさんとかいくつか問題がありますのと(最新機種がCookie対応との事なので少し状況が改善していくであろうことを切に期待しておりますが)。
「ユーザビリティの観点から、かんたんログインが手放せない」とお嘆きの方も多かろうと思う事を考えると…限りなく頭が痛い話でございます。

とりあえず「簡単には相応のリスクが伴うんだよ」という警句くらいは入れておきたいものです orz

2009-05-19

刮目して見よ！！

携帯

ニュースもとはこちら
http://blogs.yahoo.co.jp/uparupa_x_aquos/folder/991914.html
内の画像(Content-typeがおかしいようなので、localに保存して、jpeg系の拡張子をつけたりしてごらんください)。
http://img2.blogs.yahoo.co.jp/ybi/1/48/7a/uparupa_x_aquos/folder/991914/img_991914_16670779_0?1242547847

iモードブラウザ高機能化
(VGA対応・キャッシュサイズ100KB→500KB・テキストコピー対応
　Java スクリプト・Cookie対応、など)

奥様。
聞きました？
ご覧になりました？

Cookie対応

ですってよ！！！？？？
「あの」DoCoMoさんが。

「Cookie」

ですって。
えぇあの「iモード」なDoCoMoさんが！

“Cookie”!!

あらあらまぁまぁあらまぁまぁ！！
もひとつおまけにあらまぁまぁ！！

ようやくですわね！！
とっとと全機種バージョンアップしやがれですわ！！
(口調がおかしい…)

ただ…ついでに。JavaScript対応ってあたりが、本格的に怖いんですけれども orz

とはいえ…近日、携帯の認証関連は本格的に考察予定でしたが…えぇ火が付きましたともさ！！
っちゅわけで。乞うご期待ｗ

…ガセネタぢゃないといいなぁ……………

がるの健忘録

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