free as in air

2007|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|09|11|12|
2012|03|04|05|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|03|04|06|09|
トップ «前の日記(2009-02-13) 最新 次の日記(2009-02-15)» /編集

2009-02-14 [長年日記]

§ [//] LDAP

 よーわからんと思ったけど、2時間くらい悩めばそうでもないよーな。しかし信頼性のある構成とかは知らんがね。今回関係ないからいいや。

 いやでもセオリーがわかんねえからなあ。要件と合ってない気もするし。

 むしろPEAR::Authほうがわかんねえ気がしたけど、なんとなくわかったからいいや。コード読む気はないし。

 やべえ、適当すぎる。

 そういや29歳になったらし。

 追記(16 Feb)。

 家庭で使うことがあるのか良くわからんが、対応してるプロダクトならログインとか一元管理できるんで楽っちゃ楽か。

 オブジェクトDBの一種なのかなーみたいな。オブジェクトつかスキーマがあるねんな。個々のエントリはスキーマで定義してあって、エントリはツリー状に管理されると。でもスキーマが結構発散してて死ねる。というか、やっぱ辛い。PersonとGroupだけでいんじゃね。

 何かLDAPサーバ(OpenLDAPとか)入れて、phpLDAPAdmin入れたほうが早げ。

 んで、実はLDAPサーバ(というかディレクトリサービス)は認証機構とはあんま関係なくって、まあ単なるDBですな、ということを学んだ。

 とにかく検索と認証は別と。んで、認証とかエントリをどう扱うかとかセキュリティどうするかとかはアプリケーション任せってことなんだろう。

 この辺と組み合わせて権限周りまで面倒見てくれるフレームワークとかあるんかいな。いやーあってもメンドクサソウだけど。そもそもLDAPが面(ry。

 アプリケーションで必要な権限とかどうやって表現すんのかな。それともそこまで面倒見ないもの?スキーマ定義できれば適当に情報持たせたりできると思うのだけど。相互性を考えりゃ独自スキーマはうれしくないよな。

 しかしまあ、普通はRDBだよな。普通。

§ [InlineSkate] Goku's Savannah

 なんか少しウケた。