CMSのポテンシャルを引き出す─MODxで作る商用サイト

第14回MODxにおけるロールやアクセスポリシー

はじめに

前回の記事では、MODx上で会員限定のページを作るための基本設定についてお話しましたが、MODxが提供できるのは、なにも会員限定サイトだけではありません。実際には「本当にこれがオープンソースのCMSなの!?」と驚いてしまうほど細かな権限設定が可能ですので、今回は実用的な例を挙げてユーザーや権限についての解説を行っていきます。

ちなみに、これまでの見た目を少しでも解消するため、パッケージマネージャーより「andreas01」というテンプレートをダウンロードし、少しだけカスタマイズしてみました。

図1 現在のフロントエンドページの様子
図1 現在のフロントエンドページの様子

前回の補足

前回の記事では会員限定ページを作成するため、⁠himitsu-ug」というユーザーグループを作成し、リソースグループである「himitsu-rg」との関連付けを行っていましたが、その際のスクリーンショット前回の図2「コンテキスト」が正しく設定されていませんでした。正しいスクリーンショットは次の通りで、フロントエンドページのリソースについてのアクセス制限を設定するため、⁠web」というコンテキストを設定しておく必要があります。

図2 ⁠web」コンテキストを明示してリソースグループを設定
図2 「web」コンテキストを明示してリソースグループを設定

もう一点訂正があります。Loginスニペットをコールする際、情報がキャッシュされてしまうと「ログインしていないのにログインしているように見える」など、いろいろ不都合が起きる可能性があるため、スニペットは

[[!Login? &loginResourceId=`リソースID`]]

のように、キャッシュ禁止の形でコールするようにしてください。

最後に、会員限定ページとフォルダの関係についても補足説明させてください。会員限定ページを作成する際、会員限定コンテンツが格納されたフォルダ全体をリソースグループに所属させたい場合があると思います。

この場合、⁠権限管理⁠⁠→⁠リソースグループ」より、フォルダ自体をドラッグ&ドロップすることで、中身のリソース全てがリソースグループ配下に収まりそうに思えるのですが…… 残念ながらこの場合、フォルダのみがリソースグループの配下に加わってしまうだけですので、面倒ですが、全てのリソースを手動で移動させる必要があるようです。もしくは会員限定コンテンツは、全て別コンテキストに置いてしまうという手を使えば、個々のリソースについて設定を行う必要はありません。

ロールやアクセスポリシーについて

前回の記事で避けていたロールやアクセスポリシーについて説明します。

MODx Revolutionでは、ユーザーにロール(役割)を割り当てることができます。たとえば

  • userAにはパッケージを管理させるための役割を与える
  • userBにはパッケージ管理に加え、ユーザー管理を行うための役割を与える

といった具合です。ロールはグループとは別の概念なので、同グループに所属する複数ユーザーに対し異なるロールを割り当てることもできます。ここで、MODxにおけるロールとは単に「ロール名」「特権レベル」の組み合わせだけであり、ロール自体が具体的な権限を表すものではありません。

……と、なるべくわかりやすい解説を心がけているのですが、ロールやアクセスポリシーについては、だらだらと解説するよりも具体的な設定を見ていくのが一番です。今回のシナリオは次のとおりです。

営業部にuser1~user5までの5人のユーザーが在籍しており、MODxを社内での情報活用ツールとして使用することを考えます。user1~user3はある程度技術的な知識があるためコンテンツだけではなくシステムに関する部分の管理を行ってもらいたいのですが、user4とuser5の技術力はそこそこです。間違った操作でデータを削除されては困りますので、もう少し弱い権限を割り当てたいと思います。

わかりやすいよう、以上の要件をリストにしてまとめておきます。ロールは継承できるので、たとえば「user1は全てのロールの権限を継承する⁠⁠、⁠user3はuser4とuser5の持つ権限を継承できる⁠⁠、というのがポイントです。

表1 実現したい設定内容
ユーザー名グループ名権限ロール特権
レベル
user1sales全て0
user2salesユーザー管理+下位の権限を継承10
user3salesパッケージ管理+下位の権限を継承20
user4salesコンテンツ管理+下位の権限を継承30
user5sales自身のプロフィール管理(あまり意味はない…)40

ロールの作成

現時点では、ロールを設定する目的、意味が理解出来ていないとは思いますが、騙されたと思って「権限管理⁠⁠→⁠ユーザーグループとロールの管理⁠⁠→⁠ロール(役割)」より、以下のロールを作成してみてください。

表2 ロールの作成
名前特権レベル
Super User(デフォルトで存在)0
useradmin-role10
pkgadmin-role20
contenteditor-role30
selfmanage-role40
図3 4つのロールを作成した様子
図3 4つのロールを作成した様子

ロールとは、あくまでも権限の強さを表す数字であり、⁠特権レベルが10であればユーザー管理ができる」⁠レベルが5であればパッケージ管理ができる」といったように、具体的な権限の内容を表すものではありません。あくまでもロールとは、権限の継承のために使用されるもので、たとえば「特権レベルが10であれば、それよりも下位のロールがもつ権限を全てカバーできる」ことを意味します。

アクセスポリシーの設定

前述のように、ロール自体は実際の権限の内容を表すものではありませんので、⁠ユーザー管理が可能」⁠パッケージ管理が可能」といった具体的な権限設定は「アクセスポリシー」にて設定します。

「ユーザーグループとロールの管理」より「アクセスポリシー」に進んでください。試しに「Administrator」を選択し「アクセスポリシーを編集」に進むと、130個の細かいアクセス権限の全てが付与されていることがわかります。一方、⁠Content Editor」の内容をを見てみると、130個の中で、コンテンツ管理に関連する17項目のみがチェックされていることがわかります。これらのポリシーは「Policy Templates」というテンプレートで管理されており、よく使用する項目についてはテンプレートとしてあらかじめ登録しておくことができます。

では、⁠selfmanage-role」というuser5用のロールに割り当てるためのアクセスポリシーを設定してみます。⁠Content Editor」を右クリック、⁠ポリシーの複製」を選び、このアイテムを元に設定を行うことにします。

表3 user5用のアクセスポリシー設定
名前selfmanage-pol
説明自身のプロファイルのみを変更可能なポリシー
チェック項目change_password(パスワードを変更するため)
change_profile(プロファイルを変更するため)
frames(管理画面を表示するため)
load(各オブジェクトをロードするため)
logout(ログアウトするため)

同様に、user4用のポリシーを設定します。⁠Content Editor」の内容を複製し、そのまま使わせてもらいましょう。

表4 user4用のアクセスポリシー設定
名前contenteditor-pol
説明コンテンツ管理のためのポリシー
チェック項目「Content Editor」のチェック内容と同様

user3、user2用のポリシーも次のように作成します。

表5 user3用のアクセスポリシー
名前pkgadmin-pol
説明パッケージ管理が可能なポリシー
チェック項目packages(パッケージを管理する)
workspaces(パッケージを管理する)
表6 user2用のアクセスポリシー
名前useradmin-pol
説明ユーザー管理が可能なポリシー
チェック項目access_permissions(権限管理ページを表示するため)
delete_role(ロール削除)
delete_user(ユーザー削除)
edit_role(ロール編集)
edit_user(ユーザー編集)
new_role(新規ロール)
new_user(新規ユーザー)
save_role(ロール保存)
save_user(ユーザー保存)
view_role(ロール表示)
view_user(ユーザー表示)

現在のアクセスポリシーは次のようになっています。

図4 設定済みのアクセスポリシー
図4 設定済みのアクセスポリシー

ロールとアクセスポリシーをユーザーに割り当てる

「権限管理⁠⁠→⁠ユーザーグループとロールの管理⁠⁠→⁠ユーザーグループ」より「sales」グループを右クリックし、⁠ユーザーグループを編集」に進み、それぞれのユーザーにロールを割り当てます。

図5 ユーザーにロールを割り当て
図5 ユーザーにロールを割り当て

次に、管理画面の「mgr」コンテキストのアクセス権限を設定します。⁠コンテキストのアクセス」タブより図6のようにコンテキスト、ロール、アクセスポリシーの対応付けを行います。

図6 コンテキストのアクセス設定
図6 コンテキストのアクセス設定

最後に、⁠システム⁠⁠→⁠コンテキスト」より「web」コンテキストを右クリック、編集し、⁠アクセス許可」タブより「sales」グループのデフォルトアクセスを許可しておきます。

図7 コンテキストのアクセス許可
図7 コンテキストのアクセス許可

お疲れさまでした。後は「権限管理」より「アクセス許可をリロード」⁠全セッションを初期化」を選択した後、user1~user5の各ユーザーで管理画面にログインしてみてください。ロールによる権限の違いが体感できるはずです。

最後に

MODx Revolutionの権限管理が非常に強力であることはおわかりいただけたでしょうか?

今回紹介した機能は、一般のウェブ閲覧者向けではなく社内や管理者向けの機能ではありますが、⁠コンテンツの管理者が複数存在するが、コンテンツ管理者には最低限の権限のみ与えたい」といった場合でもロールやアクセスポリシーは強力に機能します。

強力な一方、機能が複雑で、一度設定を誤ると元に戻すのが困難になる場合もありますので、テストする場合には事前のバックアップを忘れないようにしてくださいね!

おすすめ記事

記事・ニュース一覧