Movable Type CMSプラットフォーム Movable Type
ドキュメントサイト

Movable Type 5 ManualMovable Type 5 マニュアル

パーミッションの管理

最終更新日: 2012.11.20

Movable Type 4 以前のパーミッション管理

Movable Type 4 以前のバージョンでは、ユーザーが特定の操作を行う権限を持っているかどうかの判定を「特定の名前のパーミッションを持っているか」で行っており、これは以下のシンタックスを各操作毎に記述する事で実現されていました。

 $app->permissions->can_manage_pages(); 
  または
 $app->permissions->has('manage_pages'); 
  

この問題点は、操作内容(アクション)と、パーミッション名との対応が、ソースコード中にしか記述されておらず、操作毎に分散してしまっているいる事です。

あるアクション(例えば、ウェブページ内のトラックバックの全削除)が、特定のパーミッション(manage_pages)で許可されているのかを確認するためには、そのアクションのソースコードを確認する以外に方法がありません。このため、新しいパーミッションを導入するときに、他のパーミッションとの整合性をとる事が、極めて困難でした。

Movable Type 5 の新しいパーミッション管理

Movable Type 5では、この問題を改善するべく、パーミッション名とアクションを分離し、レジストリ内で一元管理できるようにしました。

ソースコード

実行できるアクションの確認処理のみを以下のように記述します。

$app->can_do('remove_all_trackbacks_on_webpages')
    or return $app->errtrans('Permission Denied');
レジストリ

パーミッションとアクションの対応関係を 以下のように記述します。

manage_pages:
    permitted_actions:
        remove_all_trackbacks_on_webpages: 1

これにより、アクション名を分かりやすくつけておけば、ソースコードに戻って確認する必要はなくなります。複数のパーミッションの間で、動作に矛盾が生じた場合にも、レジストリを定義する MT::Core や config.yaml を確認、編集すればよく、パーミッションの整合性に問題を絞って作業をおこなえます

パーミッションとアクションの関係性は、すべてレジストリ内で定義されますが、唯一の例外がsuper_userです。super_userはユーザー固有の性質であり、MTのシステム上であらゆる操作を行える特権を持ちます。

継承

Movable Type 4以前のパーミッション管理では、権限の継承をサポートしていませんでした。Movable Type 5 のパーミッション管理では、継承関係をレジストリで定義できます。

レジストリの継承関係は、MT4のレジストリでも利用されている permissions 以下の各エントリを拡張して実装されています。以下の二つのエントリが、各パーミッションのアクションへの対応を定義します。具体的な記述例は、lib/MT/Core.pmを参照してください。

permitted_actions

このパーミッションを持っているユーザーが実行できるアクションのリストを、ハッシュで記述します。

inherit_from

このパーミッションの継承元のリストです。リストへのリファレンスで記述します。

Method

MT::Permission::can_do

書式 :

 $perms->can_do($action)

MT::Permissionクラスのcan_doメソッドは、このパーミッションに紐づいたユーザーが、$action を実行可能かを判定します。実行可能なら1を、実行禁止なら0を、不明な場合にはundefを返します。

利用例 :

$perms->can_do('login_to_cms')
    or return $app->errtrans('Access Denied');
MT::Author::can_do

MT::Author クラスの can_do メソッドは、$author が $action を実行可能か判定します。実行可能なら1を、実行禁止なら0を、不明な場合にはundefを返します。デフォルトでは、システムレベル(blog_id==0)での実行権限を判定します。オプション at_least_one が真の場合、システムレベルのパーミッションを含む、最低一つ以上のブログで実行可能な場合に真を返します。

利用例 :

 $author->can_do($action, at_least_one => 1)
     or return $app->errtrans('Access Denied');
MT::App::can_do

書式 :

 $perms->can_do($action) 

MT::App クラスの can_do メソッドは、現在のログインユーザーが、$actionを実行可能かを判定します。実行可能なら1を、実行禁止なら0を、不明な場合にはundefを返します。
MT::App::can_do は、現在のログインユーザーと現在のコンテキストの blog_id に基づき、判定を行います。また、システムレベルの権限(blog_id=0のパーミッション)も考慮します。

利用例 :

$app->can_do('login_to_cms')
    or return $app->errtrans('Access Denied');

プラグインから利用する

プラグインからパーミッションを追加するためには、以下のように記述します。追加したパーミッションは、"ロールの編集" 画面に表示されます。

permissions:
   blog.your_permission:
       group: blog_admin
       label: Your New Permission
       order: 350
       permitted_action:
           your_action: 1
           your_other_action: 1

group

ロールのグループを指定します。以下の値を指定できます。

  • blog_admin
  • auth_pub
  • blog_upload
  • blog_comment
  • blog_design
  • sys_admin (システムレベルのみ)

label

パーミッションの表示名を指定します。

order

パーミッションのロール グループ内での表示順を指定します。

メニューへのアクセスをパーミッションで制限する

管理画面の特定のメニューを、パーミッションがあるユーザーのみがアクセスできるようにします。

applications:
   cms:
       menus:
           tools:my_menu:
               label: Your Menu Label
               mode: your_mode
               order: 150
               view: blog
               permit_action: your_permissions