Atmosphere Login

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

これは次の場合に適しています：

• あなたの貢献者が既に Atmosphere アカウントを持っている場合。
• OAuth アプリや招待を管理せずに、組織が管理するドメイン（*.yourcompany.com）へのアクセスを制御したい場合。
• より広範な Atmosphere の一部である何かを構築していて、スタックの残りの部分と一貫した ID を持ちたい場合。

インストール

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

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({
	integrations: [
		emdash({
			authProviders: [atproto()],
			server: {
				host: "127.0.0.1", // required for local dev — see "Local development" below
			},
		}),
	],
});

これで、ログインページとセットアップウィザードに Atmosphere でサインインが表示されます。許可リストが設定されていない場合、最初のユーザーが管理者になり、その後は全員の自己登録が閉じられます — 開くには許可リストを参照してください。

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

設定

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

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

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

許可リスト

allowedDIDs も allowedHandles も設定されていない場合、最初のユーザーのみがサインアップできます — 他の誰かがログインしようとすると signup_not_allowed で拒否されます。既存のユーザーは許可リストに関係なくいつでも再ログインできます（したがって、リストから自分を削除してもロックアウトされませんが、新しい人も入れません）。

少なくとも1つの許可リストが設定されている場合、いずれかのリストが一致すればユーザーが許可されます：

• DID マッチ。 ユーザーの DID が allowedDIDs にある場合。DID は移動や偽装ができない暗号化識別子であるため、これが最も厳格なゲーティング形式です。
• ハンドルマッチ。 ユーザーのハンドルが allowedHandles のエントリと完全に一致するか、先頭ワイルドカードパターン（*.example.com は alice.example.com および bob.team.example.com と一致）を介して一致する場合。

ハンドルは変更可能ですが、ハンドル許可リストは安全です。ハンドルマッチを介してユーザーを許可する前に、EmDash はハンドルの DNS/HTTP レコードを独自に解決し、プロバイダーが主張するのと同じ DID を指していることを確認します。不正なプロバイダーは、単に you@yourcompany.com を所有していると主張することはできません。

デフォルトロール

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

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

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

以降のログインでも同じフローが実行されます：ハンドルを入力し、プロバイダーで認証し、サインインした状態で EmDash に戻ります。

ローカル開発

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 の開発サーバーであり、Vite はデフォルトで localhost にバインドします。ループバック 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”

コールバックには正常に到達しましたが、許可リストが設定されておらず、あなたは最初のユーザーではありません。allowedDIDs/allowedHandles に自分を追加するか、既存の管理者に招待してもらい、ログイン時にユーザーが既に存在するようにします。

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

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

自己ホストハンドルのハンドル解決が失敗する

プロバイダーは、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 は影響を受けません — 直接照合されます。