公開フィールドと管理機能の認証境界を分ける

画面実装とendpoint実装を未認証で利用できる公開経路にし、画面実装とendpoint実装はlogin済みの指定所有者だけが利用できる管理経路として分離した。

• 管理認証policyはJWTのsubjectと設定済み所有者を比較し、authorized、unauthenticated、forbiddenを区別する。
• 管理認証境界と認証proxyの両方で管理identityを確認する。
• 未認証の管理画面はloginへ送り、別の認証利用者は管理dataへ進めない。

公開data adapterはserver内だけでSecret Keyを使い、すべてのqueryでowner、project、公開許可sessionを明示的に絞る。browserからのRealtime database接続は外し、公開画面はAPIの定期取得と画面復帰時の再取得へ切り替えた。

database migrationの正本をこのアプリ側へ集約し、同期dataをcodex schema、公開設定をapp schemaへ移した。public schemaから固有objectを除き、匿名利用者と一般認証利用者が両schemaへ直接accessできないgrantと行制御を設定した。

• Secret Keyはserver内に限定し、browserへ公開するprefixを付けない。
• 公開APIは許可session配下のsnapshotだけを返し、管理用queryや自由なdatabase accessを提供しない。
• test用identityとpathは合成値へ置き換え、個人環境の値を成果物へ含めない。

管理認証policyと同期adapterを追加し、管理identity、公開dataのowner・project・session境界を検査した。local databaseのfresh resetとschema smoke test、remote側のschema切替、key別access、実際のHTTP応答も確認した。

認証境界はroute種別とsubject判定を分け、public viewとowner-only administrationを同じbrowser認証へ結びつけない設計にした。