管理画面の守り方
このページで決めること：EmDashの管理画面へのログインを、どの方式で守るか
決める前に知っておくこと
EmDashの管理画面（/_emdash/admin）には、次の3つのログイン方式があります。
| 方式 | 仕組み |
|---|---|
| パスキー | 既定の方式です。パスワードを使わず、端末やパスワード管理ツールに保存した認証情報で、指紋・顔認証・PINなどを使ってログインします。認証情報はサイトのドメインに結び付くため、フィッシングに強い方式です |
| ログインプロバイダー | GitHubとGoogleのログインがEmDashに含まれています。パスキーに追加する形で使います。Atmosphere（AT Protocol）のログインは別パッケージで追加します |
| Cloudflare Access | Cloudflareの手前で、組織のIDプロバイダーでユーザーを認証します。本番環境では唯一の認証方式になり、パスキー、ログインプロバイダー、マジックリンク、招待、自己登録は使えなくなります。ローカルでの開発中はパスキーに戻ります |
どの方式でも、EmDashのユーザーにはロール（閲覧者・寄稿者・投稿者・編集者・管理者の5段階）が付き、できる操作が決まります。最初のユーザーは必ず管理者になります。
パスキーをすべて失った場合は、別の管理者にマジックリンクを送ってもらって復旧します。マジックリンクにはメール送信の設定が必要です。管理者が1人だけで、メールも設定していない場合は、データベースを直接操作して認証を戻すことになります。
公式の推奨
- パスキーは、ノートパソコンとスマートフォンなど、複数の端末に登録しておきます。（公式「認証」）
- 招待やマジックリンクを使う前に、メール送信の設定をします。本番のWorkersには既定のメール送信の仕組みがありません。（公式「認証」「Cloudflareへのデプロイ」）
- Cloudflare Accessを使う場合、Accessのアプリケーションとポリシーは
/_emdash/*全体にかけます。/_emdash/admin/*だけを守ると、REST APIにEmDashが必要とするJWTが届きません。（公式「認証」） - AccessのアプリケーションのAudience（AUD）タグは、
astro.config.mjsに書かず、CF_ACCESS_AUDIENCEなどの実行時の環境変数に入れ、pnpm wrangler secret putで登録します。（公式「認証」「Cloudflareへのデプロイ」）
別の選択肢が合う条件
組織のIDプロバイダーでユーザーをまとめて管理し、グループごとにロールを割り当てたい場合は、Cが合います。その場合は、本番で招待が使えなくなることと、自動処理からのアクセス方法を別に確かめる必要があることに注意します。寄稿者が多く、各自のGitHubやGoogleのアカウントでログインさせたい場合はBが合います。Bでは、提供元が確認済みのメールアドレスを返したときだけ、既存のEmDashのユーザーに自動で結び付きます。
根拠にした公式ページ
- 認証（原文：https://docs.emdashcms.com/guides/authentication/）
- Cloudflareへのデプロイ（原文：https://docs.emdashcms.com/deployment/cloudflare/）
- シークレットとキーの管理（原文：https://docs.emdashcms.com/deployment/secrets/）
- Cloudflare WorkersでのCloudflare Access（https://developers.cloudflare.com/workers/configuration/cloudflare-access/）
- Cloudflare Accessのポリシー（サービストークン）（https://developers.cloudflare.com/cloudflare-one/access-controls/policies/）
- Cloudflare Zero Trust（プラン）（https://developers.cloudflare.com/cloudflare-one/）
- MCPサーバーリファレンス（原文：https://docs.emdashcms.com/reference/mcp-server/）