Atmosphere ログイン

@emdash-cms/auth-atproto パッケージは、EmDash に Atmosphere アカウント ログインオプションを追加します。Atmosphere アカウントは、Bluesky やその他の AT Protocol ネットワーク上のアプリで使用される、ポータブルでユーザー所有のアイデンティティです。ユーザーはハンドル（例：alice.bsky.social）でサインインし、自分のプロバイダーで認証します — EmDash はパスワードを見ることがありません。

以下のような場合に適しています：

• コントリビューターがすでに Atmosphere アカウントを持っている。
• OAuth アプリや招待を管理せずに、組織管理のドメイン（*.yourcompany.com）でアクセスを制御したい。
• 広い Atmosphere の一部となるものを構築しており、スタックの残りと一貫したアイデンティティが必要。

インストール

プロバイダーパッケージをインストールします：

pnpm add @emdash-cms/auth-atproto

EmDash インテグレーションにプロバイダーを追加します：

import { defineConfig } from "astro/config";
import emdash from "emdash/astro";
import { atproto } from "@emdash-cms/auth-atproto";

export default defineConfig({
	server: {
		host: "127.0.0.1", // ローカル開発に必須；以下を参照
	},
	integrations: [
		emdash({
			authProviders: [atproto()],
		}),
	],
});

これだけでログインページとセットアップウィザードに Sign in with Atmosphere が表示されます。許可リストが設定されていない場合、最初のユーザーが Admin になり、それ以降は全員のセルフサインアップが閉じられます — 開放するには許可リストを参照してください。

プロバイダーはパブリック OAuth クライアントで、/.well-known/atproto-client-metadata.json に独自のメタデータドキュメントを提供するため、上記の設定だけで動作します — 環境変数、クライアントシークレット、OAuth アプリの登録は不要です。

アクセスの設定

atproto() プロバイダーは許可リストとデフォルトロールを受け付けます：

atproto({
	allowedDIDs: ["did:plc:abc123..."],
	allowedHandles: ["*.example.com", "alice.bsky.social"],
	defaultRole: 30, // 著者
});

完全なロール階層は、メインの認証ガイドに記載されています。

許可リスト

allowedDIDs も allowedHandles も設定されていない場合、最初のユーザーのみがサインアップできます。すでに EmDash ユーザーにリンクされているアカウントはサインインを続行できますが、新しいアカウントは signup_not_allowed で拒否されます。

少なくとも1つの許可リストが設定されている場合、既存ユーザーのログインを含め、すべてのログインが一致する必要があります。設定されたリストから既存ユーザーの DID とハンドルを削除すると、そのアカウントのサインインが防止されます。ユーザーはいずれかのリストが一致すれば許可されます：

• DID 一致。 ユーザーの安定したアカウント識別子が allowedDIDs の値と正確に一致する。
• ハンドル一致。 ユーザーのハンドルが allowedHandles のエントリと、正確に、または先頭ワイルドカードパターン（*.example.com は alice.example.com と bob.team.example.com に一致）で一致する。

ハンドルの許可リストは、ハンドルが変更可能であっても安全です。ハンドル一致でユーザーを許可する前に、EmDash はハンドルの DNS/HTTP レコードを独立して解決し、プロバイダーが主張するのと同じ DID を指していることを検証します。不正なプロバイダーは you.yourcompany.com を所有していると単純に主張することはできません。

デフォルトロール

許可されたユーザーは defaultRole で設定されたロールで着地します。セットアップを完了した最初のユーザーだけが Admin に強制されます。Atmosphere アカウントにはグループ/ロールマッピングはありません。より細かいロールが必要な場合は、ユーザーが一度ログインした後に 設定 → ユーザー からロールを変更してください。

最初のユーザーのセットアップ

Atmosphere プロバイダーが設定された新しいサイトを開始すると、セットアップウィザードが初期管理者アカウントを作成するオプションとして提示します。

以降のログインはハンドルから始まり、アカウントプロバイダーで続行し、EmDash セッションとともに戻ります。プロバイダーの OAuth 状態とトークンは EmDash セッションとは別に保存されるため、OAuth コールバックが完了し、プロバイダーが独自のセッションをリフレッシュできます。

ローカル開発

AT Protocol OAuth プロファイルでは、ループバックリダイレクト URI に localhost ではなく IP リテラル（127.0.0.1 または [::1]）を使用する必要があります。EmDash はリダイレクト URI 生成時に ://localhost を ://127.0.0.1 に透過的に書き換えますが、これは開発セッションも 127.0.0.1 で開始する必要があることを意味します — そうしないと、localhost に設定されたセッション Cookie がリダイレクトで 127.0.0.1 に着地した後に見えなくなります。

Astro の開発サーバーは Vite を使用しており、デフォルトで localhost にバインドします。Astro のトップレベル server.host オプションをループバック IP に設定します：

export default defineConfig({
	server: {
		host: "127.0.0.1",
	},
	// ...
});

その後、http://127.0.0.1:4321/_emdash/admin を開いてフロー全体を実行します。

本番環境

同じ設定が本番環境でも動作します。プロバイダーは独自のクライアントメタデータを以下で提供します：

https://your-site.example.com/.well-known/atproto-client-metadata.json

認可サーバーはログイン中にこの URL を取得してクライアントのリダイレクト URI を検証します。デプロイのサイト URL が HTTPS でパブリックインターネット上から到達可能であることを確認してください — VPN 内の内部専用デプロイは、ユーザーの認可サーバーがメタデータドキュメントを取得できないため、ログインを完了できません。

TLS 終端リバースプロキシの背後で EmDash を実行している場合は、siteUrl を設定して EmDash が正しいリダイレクト URI を構築できるようにします。これがないと、リクエストは http://internal-host:4321 のように見え、メタデータは認証サーバーが見るものと一致しません。

トラブルシューティング

”Account is not in the allowlist”

サインインに使用したハンドルまたは DID が allowedDIDs / allowedHandles に含まれていません。ワイルドカードパターン（*. で始まる必要があります）を確認し、ハンドル一致は DNS/HTTP に対して検証されることを覚えてください — ハンドルの DID レコードが現在プロバイダーが返した DID と同じものに解決しない場合、一致は拒否されます。

“Self-signup is not allowed”

コールバックには正常に到達しましたが、許可リストが設定されておらず、最初のユーザーでもありません。アカウントの DID を allowedDIDs に、または検証済みハンドルを allowedHandles に追加してください。メール招待は Atmosphere DID を EmDash ユーザーにリンクしません。

ログインがエラーなしでログインページにリダイレクトされる

これはほとんどの場合、ローカル開発で説明されているループバック Cookie の問題です。http://127.0.0.1:4321（server.host: "127.0.0.1" を設定した後）で管理画面を開いて再試行してください。

セルフホストハンドルのハンドル解決が失敗する

プロバイダーは DNS-over-HTTPS（Cloudflare の DoH エンドポイント）と HTTP /.well-known/atproto-did ルックアップを競争させてハンドルを検証します。セルフホストハンドルには少なくとも以下のいずれかが必要です：

• did=<your-did> を含む _atproto.<handle> DNS TXT レコード、または
• DID を含む https://<handle>/.well-known/atproto-did ファイル。

両方の方法が失敗すると、基礎となるアカウントが有効であっても、ハンドル一致は拒否されます。allowedDIDs の DID は影響を受けません — 直接照合されます。