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つの選択肢を提示してきました。

Cloudflare Email Sending：公式がネイティブにサポートしており、Cloudflareのエッジをそのまま利用してメールを送信できます。
Resend：EmDash公式が推奨するサードパーティ製プラグインです。
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のコア設定に基本サイトアドレス（siteUrl）の明示的な定義が欠けていたのです！siteUrlが明示的に指定されていない場合、EmDash内部の絶対リンク生成ロジックとWebAuthnが依存するRP IDは、どちらもWorkersの元の一時ドメインにフォールバックしてしまいます。そこで、プロジェクトの設定ファイルに以下を追加しました。

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

再ビルドしてデプロイしたところ、マジックリンクのアドレスが正しくなり、Passkeyもカスタムドメインで正常に紐付けられるようになりました。

まとめ

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

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

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

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

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