AstroからEmdashへの移行で踏んだ落とし穴（その2）

前回の記事では、Claude Codeの助けを借りてAstroからEmDashへの移行を進めた話を紹介しました。デプロイ自体はスムーズでしたが、記事の最後に残した伏線は実際の危機でした。独自ドメインを紐付けた後、Passkeyでのログインが効かなくなり、しかも管理画面にはメールサービスが未設定との表示が出たのです。今回は、この「脱出」と認証修復の全過程を詳しく記録します。

なぜ「ロックアウト」されたのか？

独自ドメインをCloudflare Workerに解決させた後、私は意気揚々とhttps://epona.me/_emdash/adminを開いてログインしようとしましたが、Passkeyの検証が一切表示されませんでした。

冷静に考えると、これはWebAuthnのセキュリティ設計によるものです。Passkeyの認証情報はアクセスするドメイン（Origin / Relying Party ID）に厳密に紐付いています。当初*.workers.dev 临时域名下注册的凭据，在epona.meの下で作成した認証情報は、当然ながら新しいドメインでは機能しません。

そんな時、システムはメールでのログインを提案してきましたが、困ったことに——デプロイしたばかりで、メールサービスは何も設定していませんでした。幸い、*.workers.dev/_emdash/adminを使って管理画面にはログインできました。

EmDashにメールサービスを設定する

管理画面に入れた以上、最優先でメールサービスを設定し、再びロックアウトされる事態を防ぐ必要があります。

プラグインの選定

管理画面のSettings → Emailを開くと、No email provider configuredと表示されていました。こうした設定は当然、Claude Codeに任せるのが一番です。

調査の結果、Claude Codeは3つの選択肢を提示してきました。

1. Cloudflare Email Sending：公式のネイティブ対応で、Cloudflareのエッジを利用してメールを送信します。
2. Resend：EmDash公式が推奨するサードパーティ製プラグインです。
3. Postmark / AWS SESなどの従来型SMTP/APIサービス。

このブログの技術スタックはCloudflareファミリー（Workers + D1 + R2）で統一しているため、外部のサードパーティ依存はできるだけ増やしたくないと考え、Cloudflare Email Sendingを選びました。

注：この機能を利用するにはCloudflare Workersの有料プラン（月額5ドル）への加入が必要です。金額も手頃で、今後ほかの高度な機能も使う予定があるため、この機会に有料プランへアップグレードしました。

プラグインのインストールとテスト

Claude Codeの案内に従い、EmDashにメールプラグインをインストールして有効化しました。デプロイが反映されると、EmDashの管理画面の左側メニューに新しいCloudflare Emailの項目が追加されました。送信元アドレスを設定し、テスト欄に自分のメールアドレスを入力して送信ボタンを押すと——無事にテストメールが届きました！

siteUrlの問題

メールサービスが使えるようになったので、workers.devからログアウトし、独自ドメインhttps://epona.me/_emdash/adminでメールログインを試しました。今回はメールは確かに届いたのですが、不可解なことに、メール内のログイン用リンク（マジックリンク）が依然として*.workers.devを指していたのです。ログイントークンの検証では送信元ドメインが厳密にはチェックされないため、仕方なくリンクを手動でコピーし、先頭のドメインを自分のepona.meに書き換えて強引にログインしました。

続いて、この状態でも独自ドメインにPasskeyを追加できない原因をAIに調査させました。AIの分析により、核心となる問題が判明しました。EmDashのコア設定に、基本サイトURL（siteUrl）の明示的な定義が欠けていたのです。siteUrlが明示されていない場合、EmDash内部の絶対リンク生成ロジックやWebAuthnが依存するRP IDは、Workersの元の一時ドメインにフォールバックしてしまいます。そこで、プロジェクトの設定ファイルに以下を追加しました。

emdash({
    siteUrl: "https://epona.me",
    // ... 其他配置
})

再ビルドしてデプロイすると、マジックリンクのアドレスが正しくなり、Passkeyも独自ドメインで問題なく紐付けられるようになりました。

まとめ

今回のヒヤリとするログイン認証の設定を振り返ると、友人に共有したい教訓が2つあります。

1. 設定の順序原則：まずドメインを決め、それから認証を設定する

Cloudflare WorkersのようなフルスタックCMSをデプロイする際は、最初のステップとして設定ファイルに独自ドメインのsiteUrlを明記し、ドメインを紐付けるべきです。一時ドメインのまま全アカウントや認証情報を設定してしまうと、後で痛い目に遭います。

2. 複数のログイン手段の冗長化は必須

現代のWebで推奨されるパスワードレス（Passkey）ログインは体験が素晴らしい一方、Originに強く紐付くという物理的な特性から、フォールトトレランスが低いです。本番公開前に必ずメールサービスをフォールバック手段として先に有効化しておかないと、ドメインや認証情報に変更があった際に、自分自身を完全に締め出してしまう危険性があります。