管理画面

Crowi の管理画面は、サイト全体の設定・ユーザー管理・プラグイン構成を Web UI から行うための領域です。/admin を開くとダッシュボードが表示され、 左サイドバーから各セクションへ移動できます。

管理画面へのアクセス

• 管理画面は 管理者のユーザーだけ がアクセスできます。 権限のないユーザーが /admin 配下を開くと「アクセスが拒否されました」 カードが表示されます。
• 認可は API 側でも二重に確認されます。管理用の API は管理者のみに限定 されているため、画面を迂回したリクエストも拒否されます。
• 最初の管理者は、インストーラーで最初に作成されたユーザーに自動付与 されます。その後の管理者付与は Users セクションから行います。

Tip: 管理者権限は強力です。日常の編集作業には通常ユーザーで ログインし、設定変更が必要なときだけ管理者アカウントを使うことを おすすめします。

ダッシュボード

/admin のトップには、各セクションへのカードが並びます。サイドバーの 見出しは以下のグループに分かれています。

ロード済みのプラグインは、設定画面へのリンクとしてサイドバーに自動で並びます。 どのグループに入るかはプラグイン側の宣言で決まり、宣言が無い場合は、そのプラグインが 提供する機能 (ストレージ / 検索 / レンダラー / メール) に対応するグループへ入ります。 対応する見出しが無いものは「設定」グループに入ります。

たとえば Elasticsearch 検索プラグインは「検索」グループに、PlantUML レンダラープラグインは「レンダラー」グループに現れます (どちらも 設定スキーマを持つプラグインのみ表示されます)。

App

サイトの基本設定です。

• サイトのタイトル などアプリ全体に関わる項目を設定します。
• 機密情報を含むキーは入力時にマスクされ、空のまま保存すると既存値が 保持されます (誤って空欄で上書きしないための挙動です)。

Security

新規ユーザー登録の挙動に関する設定です。

• 登録モード (registrationMode): 新規ユーザー登録の挙動を制御します。
  • Open — 誰でも登録可能。メール確認後すぐに利用できます。
  • Restricted — 誰でも登録申請できますが、利用開始には管理者の承認が 必要です (申請者は承認待ち状態で作成され、Users の「ユーザー 承認」キューに表示されます)。
  • Closed — 公開登録を受け付けません。管理者による招待のみで アカウントを作成できます。このモードでは /register 画面はフォームを 出さずに招待制の案内を表示し、ログイン画面の「新規登録」リンクも 非表示になります (送信前に導線が閉じます)。
• 登録許可メールアドレス (registrationWhiteList): 登録を許可する メールアドレス / ドメインの一覧です。Closed 以外の全モードで評価 され、空の場合は制限なしです。1 行 1 エントリで、次のように一致します (大文字小文字は区別しません)。
  • admin@example.com — その完全なアドレスのみ
  • @example.com — そのドメインの任意のローカルパート
  • example.com — そのドメイン、またはそのサブドメイン

Note: サイト全体に HTTP Basic 認証をかけたい場合は、Crowi ではなく 前段のリバースプロキシ側 (nginx など) で設定してください。

Authentication

認証方式に関する設定です。

この画面は読み取り専用の説明のみです。 サードパーティ (Google / GitHub) サインインはコアから取り除かれており、 それに依存する 2 つの設定は編集できません。

• 外部認証の必須化 と パスワード認証の無効化 は、有効にすると 全アカウントがログイン手段を失うため、UI にトグルが表示されず、 API も有効化しようとするリクエストを 400 THIRD_PARTY_AUTH_UNAVAILABLE で拒否します。
• どちらの設定も、将来の認証プロバイダプラグインのために非活性のまま 残されています。過去に有効化された値が残っている場合は、画面に警告が 表示されます。

Note: Google などの外部サインインの設定は、この画面ではなく プラグイン設定 (/admin/plugins) 側にあります。手順は 外部アカウントでのサインイン を参照してください。この画面に残っている 2 つのログイン方式の設定は、まだプラグイン方式の認証を前提にした形に なっていないため、引き続き編集できません。

Mail

メール送信の設定です。 対応します。

• この画面で編集できるのは 送信元アドレス (from) だけ です。
• いま有効なメールドライバ名が読み取り専用で表示され、その接続情報を 編集するプラグイン設定画面へのリンクが出ます。SMTP のホスト / 認証、 Resend の API キー、SES の AWS 認証情報は /admin/plugins 側にあります。
• テスト送信 ボタンで、ログイン中の管理者の登録メールアドレス宛に テストメールを送り、設定が正しいか確認できます (使われるのは保存済みの 設定です)。

詳細は メール送信の設定 を参照してください。

Users

ユーザーの一覧・検索・管理を行います。

ユーザー名の形式

招待を受諾したユーザーが自分で決めるユーザー名は、半角英数字と _ - のみ、1〜64 文字に制限されます。同じ規則が自己登録と初期管理者の作成 (installer) にも適用され、条件を満たさない値はアカウントが作られる前に 400 で拒否されます。

これは @メンション が認識する文字種と一致させたもので、/user/<ユーザー名> というページの名前空間が壊れないようにするためのものです。すでに登録 されているユーザー名はそのままで、新規作成・変更時にのみ適用されます。

招待済みユーザーの行では、行内に 「招待を再送」 ボタンが直接表示され、 その横の行メニューに「メールアドレス変更」「削除」の 2 つが並びます (まだ アクティベートされていないため、編集・権限変更・ステータス変更は表示され ません)。

「招待を再送」を押すと、新しい招待トークンを発行して招待メールを再送します。 招待トークンの有効期限は 7 日 です。古いトークンを明示的に無効化する必要は なく、受諾時のステータス判定で二重受諾は防がれます。なお、メール送信には SMTP などのメール設定が必要で、メール送信が未設定の場合は再送できません (送信に失敗するとエラーが表示されます)。

Tip: パスワードリセットで返される平文パスワードはその場でしか 表示されません。リセット後は速やかに本人へ安全な経路で伝え、初回 ログイン後にユーザー自身で変更してもらってください。

Note: 管理画面からのパスワードリセットは、そのユーザーの既存の ログインセッションをすべてサインアウト します。アカウントが乗っ取られて いる疑いがあるときは、リセットすること自体が侵入者を追い出す手段に なります。あわせて、そのアカウント宛にすでに送信済みのパスワード リセットリンクと、本人が申請してまだ確認していないメールアドレス変更も 無効になります (新しいパスワードでサインインしたあと、申請し直して もらえます)。個人アクセストークン と OAuth 連携アプリは影響を受けません — これらは別の資格情報として扱われ、持ち主が自分の設定画面から失効させ ます (ユーザーページとプロフィール 参照)。これらも まとめて止めたいときは、ステータスを 凍結 (SUSPENDED) にしてください。 凍結されたユーザーのリクエストは、どの資格情報を使っていても拒否されます。

ユーザー承認

Restricted モードで作成された 承認待ち (REGISTERED) ユーザー が 1 人以上いると、サイドバーの「ユーザー管理」直下に 「ユーザー承認」 メニューが件数バッジ付きで表示されます (管理者が承認待ちに気付ける ようにするためです)。/admin/users/pending を開くと承認待ちユーザーの 一覧が表示され、各行の「承認」ボタンでアクティベート (ACTIVE 化) できます。 件数バッジは一定間隔で更新されます。

Storage

添付ファイルの保存先 (ストレージドライバ) の状態を確認する read-only な 画面です。

• 現在アクティブなドライバと、ロード済みの全ドライバ一覧が表示されます。
• ドライバの切り替えは管理画面からは行いません。crowi.config.json の storage.driver を書き換えて api を再起動します。
• ドライバ間のファイル移行は crowi-admin rebuild storage copy --from <a> --to <b> CLI で行います。

ストレージ全般の設定とプラグインについては ストレージ設定 を 参照してください。

Plugins

ロード済みプラグインの一覧と、各プラグインの設定編集を行います。

• /admin/plugins でロード済みプラグインを一覧表示します。
• /admin/plugins/edit?name=<プラグイン名> で個別プラグインの設定を 編集します。フォームはプラグインが宣言した設定項目から自動生成され、 機密フィールドは「値が設定済みか」だけが往復し、平文は表示されません。
• フィールドのラベルと説明は、プラグインが翻訳を同梱していれば 管理画面の表示言語に合わせてローカライズされます (未対応の言語や フィールドはプラグイン側の既定文言にフォールバック)。
• レンダリング結果のキャッシュをプラグイン単位 / 全体でクリアする操作も ここから行えます。

保存後の接続確認

プラグイン設定を保存すると、そのプラグインが接続確認に対応していれば、保存した値で実際に接続を試して結果を表示します。対応しているのは現在 @crowi/plugin-storage-local と @crowi/plugin-storage-aws-s3 (書き込み → 読み出し → 削除の往復)、@crowi/plugin-search-elasticsearch (クラスタ情報の取得のみ) です。

確認は保存の後に走り、保存を巻き戻しません。 失敗しても値は保存済みで、表示は「保存済みですが検証に失敗しました」となります。理由は 接続できませんでした / 認証に失敗しました / 対象が見つかりません / 書き込み権限がありません / 不明なエラー の 5 つに丸められ、バックエンドが返した生のメッセージは画面に出しません。

2 点、運用上の注意があります。

• 結果は「応答を返したインスタンスでの結果」です。 複数インスタンス構成でも横断集約はしないので、あるインスタンスからは繋がるが別のインスタンスからは繋がらない、という状態はこの表示では判別できません。
• ストレージの往復確認は後始末の削除を独立した予算で撃ちますが、その削除の失敗は判定を覆しません。DeleteObject 権限だけが無い資格情報では「接続を確認しました」と出たまま、保存のたびにプローブ用オブジェクトが 1 つ残ります。

確認が走っている間、フォームは操作できません (送信していない値が「保存済み」として扱われるのを防ぐためです)。

認証プラグインの資格情報を変更するときの確認

@crowi/plugin-google のような認証プラグインの OAuth クライアント資格情報を変更しようとすると、そのプロバイダで既に連携しているユーザーがいる場合は確認ダイアログが出ます。連携中の人数が表示され、変更するとその人たちがサインインできなくなる可能性があることが示されます。「変更する」を押すと保存され、キャンセルすると保存されず入力値はフォームに残ります。

確認が要求されるのは、資格情報が atomic group (クライアント ID とシークレットのように、揃っていて初めて意味を持つフィールドの組) として宣言されていて、そのメンバーのいずれかを変更したときです。したがって clientSecret を送らず clientId だけを変えた場合も確認の対象になります — 保存済みのシークレットが、それが発行されたものとは別のクライアントと組み合わされてしまうためです。atomic group に属さないフィールドだけを変更する保存や、認証ドライバを登録していないプラグイン (ストレージ / 検索など) の保存は、この確認の影響を受けません。

API を直接叩く場合は、PUT /admin/plugins/config が 409 LINKED_IDENTITIES_EXIST を連携件数付きで返します。同じリクエストに confirmLinkedIdentities: true を付けて再送すると保存されます。このフラグはプラグイン設定として保存されることはありません。

プラグインの導入・管理は プラグインの導入と設定 を、 プラグインの仕組みは プラグインアーキテクチャ を参照して ください。

ページ削除記録

利用者がページを完全削除すると、Crowi は削除されたページの ID、最後の path、 実行者、日時、削除モードを管理者専用の削除記録として保存します。本文、ACL、 共有トークン、リクエスト情報は保存しません。この ID が指すのは削除済みの ページであり、現存するページへの参照ではありません。path が後から再利用されても、 新しいページとは結び付けずに過去の削除を調査できます。

削除記録は自動期限切れになりません。閲覧頻度の低いページでは調査が削除から 長期間後になることがあるためです。プライバシー上の要請などで消去が必要な場合は、 管理者が記録を 1 件、または 1 つの path に限定して明示的に消去します。対象を 指定しない一括消去はできず、消去操作は実行した管理者と対象の識別子をサーバー ログに残しますが、消去した記録の内容は残しません。

参照と消去の API は管理者専用です。通常のページ履歴には削除記録を表示しません。 また、この機能を導入する前に完全削除されたページについては、過去の記録を復元 できません。

Search

検索ドライバの状態を確認する画面です。

• 現在アクティブな検索ドライバと、インデックスの状態を表示します。
• インデックスの再構築は管理画面ではなく crowi-admin rebuild search CLI で行います。
• Elasticsearch などの検索バックエンドプラグインは、自動でこの「検索」 グループに設定画面へのリンクとして並びます。

詳細は 検索バックエンドのセットアップ を参照してください。

rendered AST の再構築 (rebuild rendered-ast)

crowi-admin rebuild rendered-ast は、各ページの現在のリビジョンに保存されているレンダリング済みの結果を、稼働中のレンダラーで作り直すコマンドです。rebuild search / rebuild storage copy と同じ rebuild の仲間で、何度実行しても安全です (冪等)。

# 事前検証 (書き込みなし) — 対象リビジョン数の確認だけを行う
crowi-admin rebuild rendered-ast --dry-run

# 実書き込み (バージョン bump をデプロイした直後に実行する)
crowi-admin rebuild rendered-ast

# 並列度の調整 (既定 4)
crowi-admin rebuild rendered-ast --concurrency 8

いつ実行するか (ロールアウト手順): レンダラーパイプラインのバージョンが上がるリリースをデプロイしたら、その直後に実書き込みモードで必ず実行してください。読み取り経路が保存済み AST をそのまま返すのは、そのバージョンが稼働中のパイプラインと完全一致するときだけです。したがってこれは major bump に限った話ではなく、minor / patch でも同じ扱いになります。バージョン bump 以降、古い AST を持つページは読み取りのたびにフルの再レンダリングが走ります (結果は永続化されません)。この read 増幅は backfill が完了するまでの意図された一時コストで、rebuild rendered-ast の完走によって解消されます。逆に、デプロイ前の実書き込み実行は避けてください — 事前検証は --dry-run に限定します (bump 前でも、レンダラーのバージョンが記録されていない古いリビジョンへの実書き込みが発生するため)。

完了の宣言: 保存経路は各 api レプリカが自分のバイナリのバージョンを刻むため、旧バージョンのレプリカが 1 台でも残っていると、backfill 完了後にも旧バージョンのリビジョンが新規に生まれ続けます。完了と見なすのは次の 2 条件を満たしたときだけです:

1. 全 api レプリカが新バージョンで稼働していることを確認する (旧 writer が存在しない)。
2. 最後にもう一度 rebuild rendered-ast を実行し、対象 (eligible) 残数が 0 件であることを確認する。

コマンドは冪等なので、最終再実行のコストは残数に比例するだけです。

ページ履歴の修復 (page-history repair)

crowi-admin page-history repair は、ページのメタデータ変更履歴の内部状態を修復するコマンドです。

既定ではクラッシュした writer がページに残した未処理エントリを流し切るだけで、未採番リビジョンへの採番 (--scan) と、途中で止まった rename / 削除 / 復元の着地 (--transitions) は明示的に指定したときだけ走ります。オプションの一覧は crowi-admin にあります。

# 残った outbox エントリを流す (既定)
crowi-admin page-history repair

# 未採番リビジョンへの採番だけを行う (outbox は走りません)
crowi-admin page-history repair --scan

# 両方を走らせる
crowi-admin page-history repair --outbox --scan

# 途中で止まった rename / 削除 / 復元を着地させる
crowi-admin page-history repair --transitions

--scan を単独で指定すると 既定の outbox パスは走りません。両方が必要なときは --outbox --scan と明示してください。

ページ作成・下書き作成・更新・revert・共同編集エディタの保存・crowi-admin replace url のいずれの保存経路も、リビジョンにページ内の連番を割り当て、そのページの履歴記録を有効にします。

採番はポインタ書き込みが commit された後の、独立した再開可能なステップとして走ります。保存処理の一部ではないので、2 つの間でクラッシュしても保存が失敗することはありません。取り残された採番はこの repair コマンドで回収します。

--scan は 10 分より新しいリビジョンを対象外にします。まだ進行中の採番を「失敗した採番」と誤認して二重に走らせないための猶予です。あわせて、そのページの記録開始より前のリビジョンも対象外になります (履歴の順序が狂うため)。直後に流したい場合はこの猶予より後に実行してください。

止まった移動を着地させる (--transitions)

rename・ゴミ箱への移動・復元は、ページの path を動かしてから履歴を記録するまでの間に必ず 2 回の書き込みを行います。その間にプロセスが落ちると、ページは移動先の path に居るまま「移動中」の状態で残り、通常の閲覧・一覧・検索から外れます。利用者にはページが消えたように見えます。

--transitions はこの状態を回収します。各操作について対象ページを読み、次のいずれかに分類します。

• resumed — その操作がまだ移動を所有していたので、続きを実行して着地させました。
• completed — 既に着地済みだった、対象ページが削除されていた、あるいは移動が始まってすらいなかったので、操作を終了させました。
• blocked — 書き換えていません。 判断できなかったので報告だけしています。

blocked が出たら中身を読んでください。操作 ID・ページ ID・path が必ず添えてあります。

• transition-owned-by-another-operation — 別の操作がそのページの移動を所有しています。多くはそちらが進行中なだけなので、しばらく置いてもう一度実行してください。
• unrecognised-page-state — ページが操作の記録どおりの位置にありません。手作業での確認が要ります。
• no-resumer-registered — その種類の操作を再開する手段が組み込まれていません。バグとして報告してください。

このコマンドは全部を自動で直すことを目的にしていません。判断できないものを推測で書き換えると、誰も頼んでいないページを壊しうるためです。運用者が対象を特定できるところまでが役割です。

なお grant 変更と下書きの公開は path を動かさないので、この走査の対象ではありません。