Moodle用プラグインを作る（capabilities追加）　勉強編

このエントリーをはてなブックマークに追加
Pocket

ブロックに使用するdb/access.php(DB用PHP)について、Moodle DocのNEWMODULE Adding capabilitiesに記述されています。（やっぱり英語ですが。。。）

というわけで、以下意訳。よく分からない部分は機械翻訳レベルです。

■コンテンツ

項目 意訳 内容
1. Create a file access.php in the <<NEWMODULE>>>>/db directory <<新しいMOODLE>>/dbディレクトリにaccess.phpファイルを作成 access.php内のcapabilities定義例
　1.1 Capability name (‘mod/<<NEWMODULE>>:<<CAPABILITYNAME>>) Capability名(mod/<<新しいMOODLE>>：<<Capability名>> capabilitiesの連想配列(キー)mod/<<NEWMODULE>>:<<CAPABILITYNAME>>について
　1.2 riskbitmask riskbitmask capabilityの設定値
　1.3 captype captype captypeの設定値
　1.4 contextlevel contextlevel contextlevelの設定値
　1.5 archetypes archetypes archetypesの設定値
2. Get Moodle to load the updated capabilities 更新されたcapabilitiesをMoodleにロード
3. Checking the capability in your code コードのcapabilityをチェック
　3.1 Useful variations 役に立つバリエーション
　　3.1.1 Controlling overall access to a script スクリプトへの全体的なアクセスを制御
　　3.1.2 Getting a list of users with a capability capabilityによってユーザーの一覧を取得
　　3.1.3 Checking the permissions of another user 他のユーザーの権限をチェック
　　3.1.4 Excluding administrators 管理者を除く
　　3.1.5 Performance considerations パフォーマンス考慮
4 See also 関連項目

１　<<新しいMOODLE>>/dbディレクトリにaccess.phpファイルを作成

定義したいcapabilitiesの一覧を含めなければなりません。
例：

$capabilities = array(
    'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>' => array(
        'riskbitmask'  => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
        'captype'      => 'write',
        'contextlevel' => CONTEXT_MODULE,
        'archetypes'   => array(
            'student'        => CAP_ALLOW,
            'teacher'        => CAP_ALLOW,
            'editingteacher' => CAP_ALLOW,
            'manager'          => CAP_ALLOW
        )
    ),
 
    // Add more capabilities here ...
)

capability定義の様々な部分は以下の通り。

　１．１　Capability名(mod/<<新しいMOODLE>>：<<Capability名>>

これは、capabilityのために使われるインターフェース名です。
内部名称に加えて、Moodleの言語ファイルに文字列として＜＜新しいMOODLE＞＞：＜＜capability名＞＞を追加し、ユーザーがインターフェースで見る名前をcapabilityに与えます。

　１．２　riskbitmask

様々な人を許可する事は、セキュリティリスクをもたらす可能性があります。例えば、フォーラムに投稿できる場合、求めていない広告を投稿されます。

ある程度はユーザーを信用しなければなりません。管理者と教師が問題が何であるかを知るため、各々のcapabilityが関連するリスクを一覧にすべきです。

Hardening_new_Roles_systemを見て下さい。’権限の上書き’->rolesページの列のアイコンリストに反映されます。

技術的に、この値はビットフィールドなので、’|’によって関連するリスク定数を結合するべきです。

典型的な値は以下：

    RISK_SPAM
    RISK_PERSONAL | RISK_XSS | RISK_DATALOSS

　１．３　captype

‘write’か’read’のどちらかでなければなりません。’write’はものを見せるためのものです。’write’はものを変更させるためのものです。

　１．４　contextlevel

このcapabilityが最も関連する環境のレベル。

モジュールを書いているなら、大抵はCONTEXT_MODULEです。（これは多くの影響を持ちません。ロールページの上書きとロールの定義で、グループcapabilitiesと並べ替えに使われます。）

　１．５　archetypes

このセクションでは、モジュールが最初にインストールされた時に与えるべきデフォルトの許可について、ロールごとに定めます。（または新しいcapabilityがアップグレードに際して見付けられた時）

通常、役割ごとに１行を追加します。この行は「’roletype’=>CAP_ALLOW」のように見えるべきです。

capabilityを得る事を望まないロールを除外する事はデフォルトです。（意味違うかも・・・）

非常に例外的に、CAP_PREVENT、CAP_PROHIBITのデフォルト権限を指定する必要があるかもしれません。

モジュールが更新された時、自動的に権限が上書きされず、一度capabilityが確立する点に注意して下さい。権限が変わった場合、管理者は手動で変更するか、強制的にcapabilitiesをロールのためのデフォルトにリセットしなければなりません。

以降、作成中。。。

2. Get Moodle to load the updated capabilities

The capabilities you defined are only read (and copied into the Moodle database) when your module is installed or upgraded. So every time you edit the db/access.php file you must

1.Increase your module’s version number by editing the file mod/<>/version.php.
2.Go to the the Administration ► Notifications page, and click through the steps to let Moodle upgrade itself. You should see the name of your module in one of the steps.

3. Checking the capability in your code

In order to check whether the current user has a particular capability, you need to use the has_capability function. To do that, first you have to get the appropriate context. In this case, it will be a module context.

1. First we need to get the $cm id, and verify that it is correct (there are lots of different ways you might do this, this is only an example.

$cmid = required_param('cmid', PARAM_INT);
if (!$cm = get_coursemodule_from_id('<<NEWMODULE>>', $cmid)) {
    error("Course module ID was incorrect");
}

2. Then you get the module context:

$context = get_context_instance(CONTEXT_MODULE, $cm->id);

3. Finally, you can actually check the permission

if (has_capability('mod/<<NEWMODULE>>:<<CAPABILITYNAME>>', $context)) {

Normally, you do 1. and 2. once at the top of a script, and then call has_capability as needed within the script with the appropriate capabilities.

　3.1 Useful variations
　　3.1.1 Controlling overall access to a script

Suppose you have a page that should only be available to users with a particular capability. For example, only users with mod/quiz:viewreports should be able to access mod/quiz/report.php. In cases like this, you can use the require_capability function:

require_capability($capability, $context);

near the top of your script. (As soon as you have got the context and called require_login is a good time.) All this does internally is

if (!has_capability($capability, $context)) {
    // Display error and exit.
}

but using require_capability makes your code simpler and is recommended. (Of course, anywhere you might print a link to a page like this, you should only print the link if the user has the right capability.)

　　3.1.2 Getting a list of users with a capability

Suppose you need to get a list of all the users with a particular capability. (For example, the quiz reports list all the users with the mod/quiz:attempt capability. Then you can use the get_users_by_capability function.

　　3.1.3 Checking the permissions of another user

There is an optional 3rd parameter to has_capability that you can use to check another user’s permissions:

has_capability($capability, $context, $otheruser->id);

　　3.1.4 Excluding administrators

Administrators have a magic ‘moodle/site:doanything’ capability that gives them every other capability. If you wish to disable that magic override for one particular capability check, you can use the optional 4th parameter to has capability:

has_capability($capability, $context, NULL, false);

However, you normally should not do this.

　　3.1.5 Performance considerations

The has_capability function has been carefully optimised, and is pretty fast and you should not really worry. However, it has to perform a fairly complex computation, and if you are going to make exactly the same has_capability call several times in a page (perhaps in a loop) it is probably worth moving the permission check outside the loop. For example don’t do:

foreach ($attempts as $attempt) {
    if (has_capability('mod/quiz:viewreports', $context)) {
        // ...
    }
}

Instead do

$canviewreports = has_capability('mod/quiz:viewreports', $context);
foreach ($attempts as $attempt) {
    if ($canviewreports) {
        // ...
    }
}

get_users_by_capability is a very expensive computation. If you are calling it more than once in your script, you are probably doing something wrong 😉

4 See also

Access API
Roles
Hardening_new_Roles_system – information about risks
NEWMODULE_Documentation – NEWMODULE Documentation front page

広告

このエントリーをはてなブックマークに追加
Pocket