ローカル開発環境の実キャプチャ
操作前の確認
実装前にAPI、認証、権限、ログの責務を切り分けます。
標準手順
画面で再現できる状態を作り、APIレスポンスとログを同じ時刻で突き合わせます。
証跡の残し方
連携失敗時はレスポンス、アクセスログ、監査ログ、外部通知の配送履歴をそろえて調査します。
画面ガイド
実際のコンソール導線に合わせて、対象機能、操作ステップ、確認ポイントを画面例で追えるようにしています。
/docs/developers
ナビゲーション
認証/組織
設定/権限
管理基盤
認証/組織
1
セッション
2
OAuth開始
3
公開文書での扱い
OAuth開始時はSet-Cookieと3xxリダイレクトを失わないことが重要です。
セッション
管理コンソールは既存のBetterAuthセッションを利用します。APIは組織slugと権限を組み合わせてアクセスを判定します。
1. セッション の確認観点
対象組織と権限が揃っていることを確認する
画面操作とAPI呼び出しで同じデータを見ていることを確認する
失敗時にアクセスログまたは監査ログで追跡できることを確認する
APIだけを見て判断せず、画面の権限ガード、組織コンテキスト、外部通知やログの記録まで含めて確認します。
実装前提、画面/API、ログの3点を同じ時刻で追える形にします。
OAuth開始
OAuth、Cookie、CORS、BetterAuth設定を変更する場合は既存の保護ルールを確認し、Set-Cookieと3xxリダイレクトを壊さないことが必須です。
2. OAuth開始 の確認観点
対象組織と権限が揃っていることを確認する
画面操作とAPI呼び出しで同じデータを見ていることを確認する
失敗時にアクセスログまたは監査ログで追跡できることを確認する
APIだけを見て判断せず、画面の権限ガード、組織コンテキスト、外部通知やログの記録まで含めて確認します。
BetterAuthのCookieとstateを維持したままGoogleへ遷移させます。
公開文書での扱い
公開文書には安全な概念説明を載せ、内部環境名やシークレット、運用アカウントは掲載しません。
3. 公開文書での扱い の確認観点
対象組織と権限が揃っていることを確認する
画面操作とAPI呼び出しで同じデータを見ていることを確認する
失敗時にアクセスログまたは監査ログで追跡できることを確認する
APIだけを見て判断せず、画面の権限ガード、組織コンテキスト、外部通知やログの記録まで含めて確認します。
実装前提、画面/API、ログの3点を同じ時刻で追える形にします。