Drupalのエンティティ（Entity）の権限管理設定は「access callback」を定義したほうが安全

hook_menuで定義したページへのアクセス権限設定は「access callback」と「access arguments」で行います。特定なユーザーロール、特定なユーザーのみなどの制御が可能となります。特に、ユーザーのアクセス権限管理ページ（ホーム » 管理 » ユーザー » 権限）で各ページのアクセス権限管理が一般的で、よく利用されます。hook_menuがこのアクセス権限管理の実装方法を纏めます。

やりたいこと

• ​アクセス権限管理ページ（ホーム » 管理 » ユーザー » 権限）へのユーザー権限管理実装
• 管理者がユーザーのロールよりカスタマイズしたページへのアクセス管理ができます

アクセス権限：既存とカスタム2種類

• 'access callback'と'access arguments'設定より特定なユーザーアクセスを制御します
  • 'access callback' => 'user_access'、 'access arguments' => array('access content')　コンテンツの参照権限（すべてのユーザがこの権限を有するべき）
  • 'access arguments'の設定値はアクセス権限一覧を参考してください
• hook_permissionを実装して、権限管理ページ（Home » Administration » People » Permissions）でアクセス権限を管理します
  • ​下記の例で詳細に実装方法を説明します

'access callback'と'access arguments'の違い

• 'access callback'： 関数名（例：'user_view_access'）として設定、関数（'user_view_access'）が呼び出され、ユーザーがこのページにアクセス権限があるか否かを判断する機能となります
  • 初期値（'access callback'が定義されていない場合）： 'user_access'
  • 例：'access callback' => TRUE が設定された場合、すべてのユーザーがアクセス可能、この時'access arguments'の設定は不要
  • '例：'access callback' => 'user_is_logged_in' の場合、関数user_is_logged_inが呼び出され、True/Falseの判断結果を 'access callback'に返します
• 'access arguments'： 配列構造、特定の権限/ロールを'access callback'に設定された関数に、引数として渡す機能となります
  • ​'access callback' => 'user_access' , 'access arguments' => array('administer users')　で設定した場合以下の権限設定となります
    • ​create entries
    • delete any entry
    • delete own entries
    • edit any entry
    • edit own entries
  •  配列に整数の設定（例：'access arguments' => array(1)）ができます。この場合、URLのパラメータを参照して、​'access callback'に設定された関数に渡します
    • ​URL例： 'foo/bar/user'
    • array(0)は'foo'、array(1)は'bar'、array(2)は'user'を引数として'access callback'に設定された関数渡します

「access arguments」設定とhook_permissonでアクセス権限を制御

• 「access arguments」関数に、hook_permissionを実装したファンクションを渡すこともできます
  • 例：　'access arguments'  => array('authorize fbauth_connect') 
  • hook_permissionを実装したファンクションは以下のようで（実に簡単の数行だけ）

    /**
     * Implements hook_permission().
     */
    function [my-module-name]_permission() {
      return array(
          'authorize fbauth_connect' => array(
              'title' => t('Connect Facebook account and store access token'),
          ),
      );
    }
    

  • ​アクセス権限管理ページ（ホーム » 管理 » ユーザー » 権限）に、このページへのアクセス権限管理が現れます
    
  • アクセス権限管理ページで、ユーザーのロールより定義したページへのアクセス管理ができます。

Drupalのモジュール（EntityAPI）がモジュール（Rules、Viewsなど）に統合機能を提供していますが、各モジュール間の統一性が欠けています

• 背景：Drupal7.56、EntityAPI7.x-1.8、Rules7.x-2.10
• モジュール（EntityAPI）がほかのメジャーモジュール（Rules、Viewsなど）に統合機能を提供して、EntityAPIがよく利用されるようになります
• ただし、各モジュール間の連携に統一性が欠けていることを気が付きました
  • 開発メンバーが違うので、開発ドキュメントが不備の場合、いろいろな誤解が生じるでしょう

例：エンティティ（Entity）へのアクセス権限管理にモジュール（Rules）が独自の権限（"save"）を生み出している

• エンティティのアクセス権限チェック関数：entity_access($op, $entity_type, $entity = NULL, $account = NULL)　（本家のentity_accessについての説明をご参考）
  • 引数$opは四つの権限：'view', 'update', 'create' or 'delete' （hook_entity_infoのパラメーター"access callback"を実装時にこの四つの権限を定義すればよいはずです）
• モジュール（Rules）がエンティティアクセスチェック時に、"save"権限を生み出しています
  • rules/modules/entity_rules.incの313行あた
  • 元々、モジュール（Rules）の"entity_save"は、「エンティティデータの保存」アクションです
  • ここで、"entity_save"を"save"に変換して、エンティティの"access callback"にパラメーターとして渡し、権限チェックをします
  • エンティティが定義している"access callback"に"save"権限を定義してなければ、権限がないと判断されます

対応方法１：モジュール（Rules）側でエンティティへのアクセス権限を再定義する

• この例を限っては、モジュール（Rules）側で、エンティティへのアクセス権限の再定義します
  • Rulesの設定で「権限チェック省略」オプションがあるので、権限チェックを行わないことができます
  • Rulesの権限管理で各タイプのユーザーに権限を付与することもできます
    

対応方法２：エンティティ側の"access callback"に"save"権限チェックを追加

• hook_entity_info()の"access callback"の実装に、"save"権限を追加します（"update"権限と同じはず）

  /**
   * Access callback for endity
   */
  function vocabulary_access($op, $entity, $account = NULL, $entity_type = NULL) {
      global $user;
  
      if (!isset($account)) {
          $account = $user;
      }
      switch ($op) {
          case 'create':
              return user_access('administer vocabulary', $account)
              || user_access('create vocabulary', $account);
          case 'view':
              return user_access('administer vocabulary', $account)
              || user_access('view vocabulary', $account);
          case 'edit':
          case 'save':    // save permission created by  entity_rule.inc
              return user_access('administer vocabulary')
              || user_access('edit any vocabulary')
              || (user_access('edit my own vocabulary') && ($entity->uid == $account->uid));
          case 'delete':
              return user_access('administer vocabulary')
              || user_access('delete any vocabulary')
              || (user_access('edit my own vocabulary') && ($entity->uid == $account->uid));
      }
  }

• サードパーティーのモジュールでは、ソースコードの変更はしないほうがよいでしょう。対応方法１をお勧めします