セッション・管理者依存エンドポイントの契約とバックエンドを実装する

[reiroop]

背景

以下のエンドポイントは、現在のセッション(traQ ID)や管理者情報に依存するため、認証サブシステム(#16)と、traQ ID ↔ Stripe Customer のマッピングが用意できてから、契約とバックエンドを併せて実装する。

マッピングは自前 DB で持つ方針:

• DB に traq_id / Stripe Customer ID / メールアドレスの sha256 ハッシュを保持する。メールアドレスは個人情報のため生では持たず(Stripe 側が保持)、ハッシュはメールアドレスから既存アカウントを検索する用途(セッションが無い再入部時などの本人特定。設計レビューで判明した会員・会計フローの要求ギャップ #22 参照)に用いる。
• 管理者情報も DB で持つ(is_admin は DB 参照)。
• traQ ID はリクエストごとに NeoShowcase プロキシの X-Forwarded-User ヘッダ(認証サブシステム(メール確認・CSRF・セッション)を実装する #16)から取得する。
• API 出力で traq_id を返す場合は、Stripe metadata ではなく DB 逆引き(Stripe Customer ID → traq_id)で解決する。

対象エンドポイント

• GET /me — セッション情報(email / traq_id / is_admin / customer_id)
• GET /me/customer — 現在のユーザーの Stripe Customer 取得
• POST /me/customer — Customer 作成(DB に traq_id と対応付けて登録)
• PATCH /me/customer — Customer 更新
• POST /me/invoices — 現在のユーザー向け Invoice 作成
• GET /admin — 管理者一覧

やること

• DB スキーマ: traq_id / Stripe Customer ID / メールの sha256 ハッシュ、管理者情報
• 上記エンドポイントの oRPC 契約(入出力スキーマ)を定義
• Stripe SDK + セッションコンテキスト + DB でバックエンドを実装(traq_id は DB 逆引きで解決)
• 認可(認可・レート制限を導入し、無認証アクセスを塞ぐ #15)を適用(ユーザー系はセッション必須、admin は DB の管理者情報で判定)

スコープ外/関連

• 認証サブシステムは 認証サブシステム(メール確認・CSRF・セッション)を実装する #16、認可・レート制限は 認可・レート制限を導入し、無認証アクセスを塞ぐ #15。
• セッション不要な Stripe カタログ/請求の管理系(CRUD)エンドポイントは、本 issue に先行して実装する。本 issue はその後段として、セッション・管理者依存のエンドポイントを担う。
• 先行実装で Stripe metadata から traq_id を返している箇所は、本 issue で DB 逆引き(Stripe Customer ID → traq_id)に置き換える。