PEAK XOOPS - イベント通知における2つの問題 in englishin japanese

Archive | RSS |
XOOPS
XOOPS : イベント通知における2つの問題
Poster : GIJOE on 2006-06-16 05:07:40 (7672 reads)

in englishin japanese
ayumiさんの指摘でイベント通知を見直しているのですが、ここに、いくつもの整合性チェック漏れがあって、かなり困った状況になっています。

(1) カーネル側のチェック漏れ
admin_only なイベントも、管理者以外が登録できる
(単にフォームに表示されていないだけ)

(2) 閲覧権限のチェックをイベント通知に渡し忘れているモジュールが多い
user_listの指定無しに一括でtriggerEvent()してしまうと、閲覧権限がチェックされない
(こちらは、モジュール側で細かく制御するしかない)


この両者があるおかげで、newbbなどではプライベートフォーラムが意味をなさないものになっています。一般ユーザが投稿文付のイベント通知を登録すれば、プライベートフォーラムの投稿も、本文付で通知されてしまうからです。

これはほぼ「穴」と言える状況でしょう。

とりあえず、xhnewbbでも最低限(2)の面倒をみてやらなければならないとは思いますが、カーネル側のバグ(1)についてはどうしたものか、頭を悩ませています。モジュール内のnotification_update.phpで自前チェックを足す、というのも手ではありますが…

admin_only なイベント通知に重要な意味を持たせているモジュール作者は、再度確認した方が良さそうです。

Printer friendly page Send this story to a friend

Comments list

GIJOE  Posted on 2006/6/17 5:06
Quote:
XOOPSの権限チェックは、しっかりしてそうに見えて結構いい加減ですよね。

理由は、
1・ページコントローラのために実装はモジュール側で100%必要
2・しかし、コアが与えてくれるgpermはいまいち使いにくい

1は、各モジュールの作者の力量と理解度によるんですが、XOOPS側で簡単に使えるクラスを作っておいてくれないかなぁと。
xoops_grouppermissionはいまいちなんですよね・・・。
groupperm.php は数少ない「onokazu製であることが保証されたファイル」ですから。
つまり、使わないのが吉です。
Catzwolfさんも本家で、「なんでこんなコードなんだ!」とか怒ってましたが、onokazuさんは例によって知らんぷりでした。

でも、groupperm.phpも単なるユーティリティクラスです。
使う使わないは、モジュール作者が決めることで、このあたりの自由度がXOOPSの魅力とも言えます。
自分のモジュールだけはちゃんと作ればいいんですよ。

「スキルの信用できる作者のモジュールしか使わない」

これ、XOOPSの鉄則ですよね。
(そうだ。newsもさっさとbulletinに移行しなきゃ)

nitificationもある意味ユーティリティクラスです。おざなりに使うから権限指定が反映されないだけで、正しい使い方(必ずuser_listを指定する)さえ知っていれば、とても便利ですよね。コードの質もかなりまともです。
kurak_bu  Posted on 2006/6/16 15:37
report issue to xoops dev team
tohokuaiki  Posted on 2006/6/16 12:45
XOOPSの権限チェックは、しっかりしてそうに見えて結構いい加減ですよね。

理由は、
1・ページコントローラのために実装はモジュール側で100%必要
2・しかし、コアが与えてくれるgpermはいまいち使いにくい

1は、各モジュールの作者の力量と理解度によるんですが、XOOPS側で簡単に使えるクラスを作っておいてくれないかなぁと。
xoops_grouppermissionはいまいちなんですよね・・・。
どこがいまいちか忘れましたが、いまいちがゆえに、exFrameではexPermクラス、xanhteでも権限用のXanhte_GpermManagerクラスでxoops_grouppermissionをラップするクラスを作成しています。PEAKシリーズで言うと、read_config.phpですよね。確か。
Login
Username or e-mail:

Password:

Remember Me

Lost Password?

Register now!