メインコンテンツへスキップ

権限

バックオフィスへのアクセスがロールと組織によってどのように制御されるか。

はじめに​

CLUAR は、組織内の人に割り当てられるロール（グループ）を通じて、バックオフィスへのアクセスを制御します。サーバーの各 REST サービスはアクセスカテゴリに分類され、正しい組織内で正しいロールを持つ人だけがそれを使用できます。

ロール​

あらかじめ作成された5つのロール（user_group）があります：

コード名前
administrator管理者
editorエディタ
author著者
contributor寄稿者
subscriber購読者
まだすべてのロールに権限が割り当てられているわけではありません

現在、実際に何らかのアクセス権を持つのは管理者とエディタだけです — アクセスルールで参照されているのはこれらのロールだけです（下記参照）。著者、寄稿者、購読者はフォームの選択肢としてはすでに存在しますが、まだアクセス権は設定されていません。これらのロールのいずれかを誰かに割り当てても、現時点ではバックオフィスへのアクセスは一切得られません。

組織​

人は組織のコンテキスト内でのみロールを持ちます — 紐付けは 組織 > メンバー（organization_people）で、個人 + 組織 + ロールを関連付けることによって行われます。

現在、組織は admins というコードの1つだけが存在し、すべての権限はそこで検証されます。エンティティ organization は階層（parent_id、親組織）をサポートしていますが、この階層は現在の権限ルールではまだ使用されていません — すべての検証は直接 admins 組織を指しています。

編集モードへの初回アクセス​

CLUAR では、ログインする場所が2つに分かれています：

  • Netuno のバックオフィス（開発時はポート 9000）— Netuno ユーザー（netuno_user、ユーザー名/パスワードのペア）と、個人やロールを含むすべてのエンティティを直接管理する場所です。
  • ウェブサイト自体の制限エリア（/login、開発時はポート 3000）— コンテンツ編集者が日常的にログインし、ページの編集モードにアクセスする場所です。

制限エリアに入り、編集モードを利用できるようにするには、ログイン情報を持つ Netuno ユーザーが個人に関連付けられ、その個人が admins 組織に管理者またはエディタのロールで紐付いている必要があります（上記の組織を参照）。

デフォルトユーザー​

CLUAR の server/setup/030-people.js はデフォルトで、id: 2 の Netuno ユーザーに紐付く「admin」という個人をすでに作成しており、server/setup/050-organization_people.js はその個人を管理者ロールで admins 組織にすでに紐付けています — つまり、このユーザーは最初から完全なアクセス権を持っています。

このデフォルトユーザーのログイン情報は次のとおりです：

ユーザー名: admin
パスワード: admin

これらの認証情報で、Netuno のバックオフィスで追加の手順を踏むことなく、管理者として直接制限エリア（/login）に入れます。

本番環境ではデフォルトパスワードを変更してください

admin/admin は広く知られた推測可能な認証情報です。サイトを本番環境に移行する前に、このユーザーのパスワードを変更してください（または新しい管理者を作成して、このユーザーを無効化してください）。

新しいユーザーの作成​

可能な方法は2つあります：

制限エリアから（推奨）: ユーザー > ユーザー作成 では、1つのフォームで名前、ユーザー名、パスワード、e-mail、組織、ロールを入力するだけで、すべてを一度に作成します。Netuno ユーザー、個人（すでにそのユーザーに紐付け済み）、選択した組織/ロールへの紐付けです。Netuno のバックオフィスを通る必要はありません。

Netuno のバックオフィスのみを使用: バックオフィスはすべてのエンティティに直接アクセスできるため、そこから離れることなく、同じ3つの手順を手動で実行することも可能です：

  1. 選択したユーザー名/パスワードで Netuno ユーザー（netuno_user）を作成します。
  2. 個人を作成し、その Netuno ユーザーに関連付けます。
  3. 組織 > メンバー で、その個人を管理者またはエディタのロールで admins 組織に紐付けます。

どちらの場合も、作成された個人はすぐに /login にログインして編集モードにアクセスできます。

権限の適用方法​

サーバーの各サービスは、server/core/_service_config.js で定義された次のいずれかのカテゴリに分類されます：

カテゴリアクセスできる人例
公開誰でも、ログイン不要お問い合わせ、アバター、ログイン
コンテンツ管理管理者 + エディタページ、バージョン、コンポーネント、辞書、アクション
サイト管理管理者のみ設定、言語、同期
アクセス管理管理者のみ組織、個人、ユーザー

これらのカテゴリのいずれにも記載されていないサービスはデフォルトで拒否されます — これはコードによる意図的な決定であり（ファイル内で明示的にコメントされています）、新しいサービスの分類を忘れた場合に、不注意による自由なアクセスではなくブロックになるようにするためです。

権限は開発環境では適用されません

dev 環境では、_service_config.js が検証の前にすべてのサービスを最初から解放します — つまり、権限が実際に適用されるのは本番/ステージングのみです。ローカルでテストする場合、ログインしているユーザーはロールに関係なくすべてにアクセスできます。

インターフェース: メニューも権限でフィルタリングされる​

サーバー側でのブロックに加えて、制限エリアのサイドメニュー（website/src/components/SideMenu）も、ログインしている個人のロールに応じて表示項目をフィルタリングします — その人が使用する権限を持たないオプションを表示しないためです。

2つのリストを同期させてください

SideMenu の「誰が何を見られるか」のリストは、_service_config.js の CONTENT_MANAGEMENT_PATHS、SITE_ADMIN_PATHS、ACCESS_MANAGEMENT_PATHS に手動で合わせて維持されています — フロントエンドとバックエンドに分かれた2つのリストです。新しい保護対象サービスを追加するときは、両方を更新する必要があります。サーバー側だけを変更するとエラーが隠れ（メニューは実際には拒否されるオプションを表示し続けます）、メニュー側だけを変更しても実際には何も保護されません。

新しいサービスを保護する方法​

  1. server/services/ に通常どおりサービスを作成します。
  2. 誰が使用できるかに応じて、サービスのパス（path/method）を server/core/_service_config.js の正しいリスト — CONTENT_MANAGEMENT_PATHS、SITE_ADMIN_PATHS、または ACCESS_MANAGEMENT_PATHS — に追加します。公開する場合は、PUBLIC_PATHS に追加します。
  3. サービスに対応する項目が制限エリアのメニューにある場合は、フィルタが実際の権限と一致するように SideMenu も更新します。