本稿ではNew access policy APIについて熱く語りたい
GroupモジュールはDrupalのユースケースを大きく変えるモジュールだ。Drupalでは、もともとコンテンツに対するオーナーシップは1ユーザーにしか与えられないから、誰か他の人がそのコンテンツを編集する必要があれば、Admin権限でやるかそのコンテンツが属するコンテンツタイプを編集可能とするロールを定義してそれを必要な人に付与する形の運用になる。実際のオペレーションでは、運用が非常に複雑になってしまう。
Groupモジュールは新たに（特定GroupTypeに属する）Groupエンティティを導入し、GroupとUserを関係づける関係エンティティを用いて、新たなアクセス制御を可能にした。同梱モジュールにGroupNodeがあり、これをインストールして、特定コンテンツタイプのコンテンツとGroupエンティティを関係づける関係エンティティが使えるようになる。GroupType単位でアクセス権を新たに定義することができ、それによって、これまで容易には実現できなかったユースケースが実現可能になった。私が関わったプロジェクトでは、ほぼ100%導入している。
今回、Drupal 10.3以降(Drupal 11を含む)でこのアクセス制御の仕組みが洗練化されてNew access policy APIとしてCoreに組み込まれた。New access policy APIにコンセプトは簡潔に述べられているが解説記事としては、Introduction to the Policy Based Access Checking in Drupal 10が秀逸だと思う。リンクは記事の2段目の図の部分を指している。UserにはRoleが与えられていて各サイトで”/admin/people/permissions”で定義された権限によりやれることが決まる。例えば、基本ページコンテンツタイプのコンテンツを新規作成できるのは管理者だけといった定義をする。
一人管理サイトであれば、全部管理者がやる形で良い。
デフォルトでは、匿名ユーザーが公開されたコンテンツを読む権限が与えられているので、公開すれば誰でもコンテンツを読むことができる。逆に、この匿名ユーザーのチェックを外すと、認証済みユーザー、つまりログインしたユーザーしか公開されたコンテンツを読むことができなくなる。シンプルで良いのだが、例えば得意先のユーザーだけが見られるページを準備したいが、他の得意先に見られては困るといったユースケースを考えるととたんに行き詰まる。顧客の数だけコンテンツタイプを準備して、顧客の数だけRoleを準備すればできないことはないが運用が回らない。新たなAccess Policy APIでは、図にあるように従前の認可条件を参照しつつ、追加的な権限をモジュール側で定義して(VariationCacheに登録して)、hasPermission()の戻り値で可否を決める。もちろん、追加的な権限が定義されなければ従来の認可管理と動作は変わらない。
Groupモジュールは従来のRoleベースを超えるニーズを充足できる画期的なモジュールとして登場した。
リードのKristiaan Van den Eynde氏は、Groupモジュールのバージョンアップとともにその処理モデルも更新し抽象化のレベルを上げた。GroupモジュールからVariationCacheとFlexible permissionsを分離し、それを使うことで、モジュール側で独自の権限ハンドリングを行うコードを書くだけで良いようにし、VariationCacheに各モジュールが定義した権限を登録（更新）し、各モジュールで定義する認可処理を多分Flexible permissionsから呼び出す形にした。このあたりはコードに直接当たらないとわからないが、新たなAccess Policy APIでは、coreがVariationCacheを含めて管理する形になっている。
Introduction to the Policy Based Access Checking in Drupal 10のScopes and identifiersでモジュール開発者がどんなコードを書くのかの例が説明されている。もちろん、使い方を間違えれば極めて重大なセキュリティホールとなるリスクを秘めているとは言え、適用できる範囲が広大であることは論を俟たない。Kristiaanさんは、営業時間内だけアクセスできるようなコードも書けるよと書いているが、組織が有する固有な認可管理に苦労してきたユーザーには福音となろう。
この機能があるからDrupalに決めるという大規模ユーザーが出てきてもおかしくないほど強力だと思う。
Groupモジュールでは、関係エンティティを認可の基礎情報として使っていて、モデル化しやすいが計算量は増える。一人のユーザーが複数のGroupに属するケースもあるし、コンテンツが複数のGroupに属するケースもあるから、汎用的な設計故の苦しみを内在している。Coreで包括的に管理できるようになったので、今後は認可機能実装のエキスパートが重用される時期が到来するのではないかと思っている。プロジェクト中の出番はそうそう多くないが、クリティカルでノウハウを必要とするだけに若手の人は密かに爪を研いでおくと良いだろう。
※この記事は、Drupal Advent Calendar 2024用に作成されたものです。