変な機能追加。あと、お風呂入りながらつらつら考えていたことのメモ。
まず変な機能追加から。
YakiBikiはフロントコントローラがindex.phpになっていて、どのモジュールを実行するのか、基本的にリクエストパラメータから取得します。まぁあとで.htaccess + mod_rewriteでそれっぽいURLに出来るようにする為のマージンですが。
で、ちょっとそれとは別に、某所で今年度中にYakiBikiを使った簡単なまとめサイト(内部イントラOnly)を作れないか、という打診を受けてます。で、そこでは認証方式が少し厳しくなるっぽい。
現状のloginモジュールは「メールアドレス」と「パスワード」ですが、あちらでは普通に「ユーザーID」と「パスワード」らしいです。
実はこの辺りは前から頭の隅にあって、結局はてなとかmixiとかOpenURLとかSNSとかLDAP認証とか始めてしまうと、どうしたって、loginモジュール周りがいろいろと入れ替えられないと/選択できないとNGになってくるわけです。
確かにloginモジュールそれ自体を柔軟にいろいろ選択できるように出来ればベターなんでしょうが、現状ではそこまでしている暇も知識も無い。じゃぁどうするか。
要は、プログラマーレベルの人間が自分の用途に簡単にカスタマイズできれば言い訳です。loginモジュールコピペして、中を適当に弄れば一丁上がり!とできれば良いのです。いえ、当面は、の話。
そこで、モジュール変換(置換?)機能を採り入れました。config.phpで
_YB('module.convert.(モジュール名)', '(自作モジュール名)');
とすることで、
http://hoge.com/?mdl=(モジュール名)
とアクセスされた時、自動で自作モジュール名に読み替えられ、
libs/ yb/ mdl/ login/ ... YBのデフォルトloginモジュール login_custom/ ... 好みの認証方式を実装したloginモジュール
とかでlogin_customが裏側で読み込まれる・・・という案配にしました。特に'module.convert.***'が空であれば、読替は行われません。
こうすることで、プログラマーがモジュールをより弄りやすくなります。例えばloginモジュールを弄りたければ、適当に丸ごとコピペしたあと、config.phpでmodule.convert.loginにコピペした新しいモジュール名を指定することで、自分で弄ったloginモジュールを簡単に動かすことができます。また、コピーさえとってあれば、config.phpでいつでも元に戻せます。
・・・というわけで、多分便利ですし、実装の手間も瞬殺だったので実装しました。
で、あとはお風呂に入ってつらつら考えたもの。
- Threadのrole制限はとりあえずはgroup, sysのみ操作できるモノとする。
- そろそろyb_make_urlみたいな関数とsmartyプラグインを作成し、urlの生成を簡略化・統一する。
- それに併せて、overloadの仕組みも導入するかも知れない。plugin/overload/(関数名).phpで、overloadポイントに指定されているものをoverloadとか。
- 最終的には、user, group, acl, category, thread それぞれに対応するrole権限をつけるようになるかも。
- また、roleはuserに直接設定するのではなく、role専用のDAOと管理画面を用意するか、あるいはgroupに設定されるようになるかも。
- また、user, group, acl, threadは、例えば新着順などで誰でも見ることは出来るようにするかも。
- アバターは今のところuserだけを想定しているが、groupにも付けるかも知れない。
- profile機能はuserにしか想定していなかったが、アバターと併せてgroupにも付けるかも知れない。
- 将来的に、例えばgroupに入るために承認が要るか否か、とか、groupの紹介文とかをgroupのprofileに突っ込み、誰でもそれくらいは見れるようにするかも知れない。SNSっぽく。
- yb_Xhwlayを拡張し、個々のEvent毎にroleチェックをかけられるようにするかも知れない。
- ログを閲覧するためのモジュールを付けるかも。
- ログのバックアップとか。また、マスタデータ系のバックアップも必要?
- userのprofileでは、アクセス元のIPを指定できたりすると良いかも。できれば任意(or _YB()設定)の数指定できたり。
- sessionハンドラを書き換える必要がありそう。特に、session_idとIPを対にし、session_idの盗聴を防ぐとか。同じIPからのログイン失敗XX回でそのIPをロックするとか。いろいろ必要になってくるので。
- ロック条件の判定処理も、overloadして、IPとsession_idとログインに失敗したuserとをどう組み合わせてロックするか考慮できれば面白い。
- あと、ログインした時に通知メールを投げる先を複数指定できると良いかも。これで、身に覚えのないloginを検出できる。
- メンテナンスモードを追加できれば面白い。また、メンテナンスが何時に終わるのかを指定して、自動開放機能が有効であれば、その時刻を経過すると自動で解除されるとか。
そんな感じです。