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));
      }
  }

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

drupal_get_formがよく見かける

• hook_menu()のプロパティ’page callback’がよく’drupal_get_form’を呼び出します

  function node_menu() {
    $items['admin/content'] = array(
      'title' => 'Content', 
      'description' => 'Find and manage content.', 
      'page callback' => 'drupal_get_form', 
      'page arguments' => array('node_admin_content'), 
      'access arguments' => array('access content overview'), 
      'weight' => -10, 
      'file' => 'node.admin.inc',
    );
  
    // …
  
    return $items;
  }

• ほかにdrupal_prepare_form, drupal_retrieve_form関数がよく見かけますが、drupal_get_fromとの違いは？

drupal_get_formがretrieving、processing過程を含め、HTMLフォームの取得に対して、drupal_retrieve_formはフォームの構造のみを取得する

• drupal_get_formが最初にキャッシュにこのフォームがあるか否かをチェックして、フォームを取得する
  • もしキャッシュにある場合、form_get_formを呼び出してフォームを返す。
  • もしキャッシュにない場合、drupal_retrieve_formを呼び出してフォームの構造（array、HTMLではない）を取得し、drupal_prepare_formでフォームを返す
• Drupal7のForm APIのワークフローの詳細説明
  

hook_menuで定義したアクセスURLに、ワイドカード’%’(任意の文字、数字)の使用ができます。例えば、あるページのURI： 「/user/123/fbconnect」、このページにuid=123のユーザーのfbconnectを表示するページとなります。ユーザーにより、uidは変わります。

実際にhook_menuでは、連想配列のキー：　$items['user/%/fbconnect']　で表現します。ここで、ワードカード’%’が使用されています。

ワイドカードが二つのパタン

パタン１：　ワイドカードのみの

• このパタンは比較的に単純で、分かりやすいです
• URLにあるワイドカードの部分を直接に「page callback」関数に定義された関数の引数として渡します。

  function [my-module-name]_menu() {
    $items['user/%/fboauth'] = array(            //ワイドカード'%'の使用
      'title' => t('Facebook settings'),
      'page callback' => 'fboauth_user_form',  //ページ定義関数の呼び出し
      'page arguments' => array(1),               //パスの1番目（0から）を引数に
      ・・・・,
    );
  
  function fboauth_user_form($uid){             //URIの1番目にあるワードカードを引数に
    $user = user_load($uid);
    ・・・
  }

• URIに指定された（'page arugments'=>array(1)）部分(%：uid)をページ定義関数（fboauth_user_form($uid)）の引数にします

パタン２：　ワイドカード＋ファンクション名

• このパタンは「Auto-loader Whitcarts」と言います
• 例：　$items['user/%user/fboauth'] = array(　・・・・・　）ではワイドカード'%'とファンクションuserと一緒に定義されています。
• パスにあるワイドカードの部分を呼びされたページ定義関数に直接に渡すのではないです
• ワイドカードを引数として、定義されたファンクションよりUserオブジェクトをロードして、ページ定義関数に渡します
  
• 上記の例では、Drupalの固有関数（user）を利用していたため、独自にそのローダー関数の定義は不要となります。
• 以下の例では、独自のローダー（custom_obj_load()）を定義しています
  
• スペシャルオブジェクトローダーの関数名は： ワードカードの後ろに定義したオブジェクト名（ここは： custom_obj）＋'_load' => custom_obj_load($obj_id)となります

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_get_formがよく見かける

• hook_menu()のプロパティ’page callback’がよく’drupal_get_form’を呼び出します

  function node_menu() {
    $items['admin/content'] = array(
      'title' => 'Content', 
      'description' => 'Find and manage content.', 
      'page callback' => 'drupal_get_form', 
      'page arguments' => array('node_admin_content'), 
      'access arguments' => array('access content overview'), 
      'weight' => -10, 
      'file' => 'node.admin.inc',
    );
  
    // …
  
    return $items;
  }

• ほかにdrupal_prepare_form, drupal_retrieve_form関数がよく見かけますが、drupal_get_fromとの違いは？

drupal_get_formがretrieving、processing過程を含め、HTMLフォームの取得に対して、drupal_retrieve_formはフォームの構造のみを取得する

• drupal_get_formが最初にキャッシュにこのフォームがあるか否かをチェックして、フォームを取得する
  • もしキャッシュにある場合、form_get_formを呼び出してフォームを返す。
  • もしキャッシュにない場合、drupal_retrieve_formを呼び出してフォームの構造（array、HTMLではない）を取得し、drupal_prepare_formでフォームを返す
• Drupal7のForm APIのワークフローの詳細説明
  

hook_menuで定義したアクセスURLに、ワイドカード’%’(任意の文字、数字)の使用ができます。例えば、あるページのURI： 「/user/123/fbconnect」、このページにuid=123のユーザーのfbconnectを表示するページとなります。ユーザーにより、uidは変わります。

実際にhook_menuでは、連想配列のキー：　$items['user/%/fbconnect']　で表現します。ここで、ワードカード’%’が使用されています。

ワイドカードが二つのパタン

パタン１：　ワイドカードのみの

• このパタンは比較的に単純で、分かりやすいです
• URLにあるワイドカードの部分を直接に「page callback」関数に定義された関数の引数として渡します。

  function [my-module-name]_menu() {
    $items['user/%/fboauth'] = array(            //ワイドカード'%'の使用
      'title' => t('Facebook settings'),
      'page callback' => 'fboauth_user_form',  //ページ定義関数の呼び出し
      'page arguments' => array(1),               //パスの1番目（0から）を引数に
      ・・・・,
    );
  
  function fboauth_user_form($uid){             //URIの1番目にあるワードカードを引数に
    $user = user_load($uid);
    ・・・
  }

• URIに指定された（'page arugments'=>array(1)）部分(%：uid)をページ定義関数（fboauth_user_form($uid)）の引数にします

パタン２：　ワイドカード＋ファンクション名

• このパタンは「Auto-loader Whitcarts」と言います
• 例：　$items['user/%user/fboauth'] = array(　・・・・・　）ではワイドカード'%'とファンクションuserと一緒に定義されています。
• パスにあるワイドカードの部分を呼びされたページ定義関数に直接に渡すのではないです
• ワイドカードを引数として、定義されたファンクションよりUserオブジェクトをロードして、ページ定義関数に渡します
  
• 上記の例では、Drupalの固有関数（user）を利用していたため、独自にそのローダー関数の定義は不要となります。
• 以下の例では、独自のローダー（custom_obj_load()）を定義しています
  
• スペシャルオブジェクトローダーの関数名は： ワードカードの後ろに定義したオブジェクト名（ここは： custom_obj）＋'_load' => custom_obj_load($obj_id)となります