画面を作る前に境界を決める
仮想のハイキングアプリで、利用者がoffline mapsと入力し、「検索」を押すとします。端末はその意図をアプリのバックエンドに送るべきであり、アーカイブ取得の費用を負担する認証情報を受け取るべきではありません。ブラウザーに配布されたコードは調べられます。配布済みのモバイルアプリからも埋め込み文字列や送信ヘッダーが分かる可能性があります。ビルド時に埋め込んだ値は、環境変数と呼んでも秘密にはなりません。
キーをバックエンドに置くことで、配布するクライアントが知る必要のある内容が変わります。必要なのは、検索語句や許可されたコミュニティなど、アプリ自身のリクエスト仕様です。アーカイブの認証ヘッダーはサーバーが付けます。ただし、この構成でもアクセス制御と慎重な運用が必要です。シークレットを移すだけでアプリ全体が自動的に安全になるわけではありません。
アプリからは小さなリクエストを受け付ける
最初の版では、バックエンドが検索語句とページ番号を受け取り、subreddit=hikingとlimit=3は自身で設定する構成が考えられます。長さや範囲を検証し、アプリが実際に対応する選択肢だけを許可してください。クライアントが指定したアーカイブのホスト、任意のクエリDSL、任意の認証ヘッダーを受け取って転送してはいけません。これはアプリ側の境界の提案であり、Reddit App APIに実装された追加エンドポイントではありません。
バックエンドからアーカイブを呼ぶときはX-API-KeyまたはAuthorization: Bearerを使います。取得用クレジットの予約前に拒否された不正なパラメーターには料金がかかりませんが、正常な空の結果にはかかります。入力検証は誤りの修正を助け、連携の動きを把握しやすくします。ただし、要求した日付の資料が収録されていることや、有効な検索が役立つレコードを返すことを証明するものではありません。
アカウントへのログインを分けて考える
サービスサイトのSecure HttpOnlyセッションCookieは、運用担当者がアカウントや請求書を管理するためのものです。APIキーは、バックエンドからの取得を認証します。ハイキングアプリ独自のログインを実装する場合、それも別の関係です。サービスアカウントのCookieを利用者へ渡したり、サービスキーの401をアプリのセッション期限切れの証拠と見なしたりしないでください。
APIキーとアカウント残高はテナント固有であり、ドメイン群の間で共有されません。redditapp.comの認証情報には、ドメインを明記して保管してください。別ブランドのキーは宛先URLを変えても有効になりません。試用資格をネットワーク共通で判断することは、別々のアカウント残高が共有プールになることを意味しません。
ログも秘密情報の境界として点検する
APIキーをバックエンドへ移したら、ログへの記録方法にも注意が必要です。リクエストのトレース、例外報告、可観測性の連携先に認証ヘッダーがコピーされていないか点検してください。処理内容と状態を診断できる記録は残しつつ、元のキー、アカウントパスワード、リクエスト内の完全な秘密情報は記録しないようにします。
利用者が行動できるメッセージを返してください。サービスキーのエラーは運用担当者への連絡、残高不足はアカウント側の判断、レート制限はリクエストを控える対応が必要です。401や402を繰り返しても原因は直りません。レスポンスを失ったリクエストは、無料の失敗や確認済みの成功と決めつけず、不明な状態として記録します。
配備先を把握したうえでキーを交換する
登録時には、支払い前にキー全体が一度表示されます。その後のアカウント画面には接頭部分だけが表示され、元のキーを復元できるコピーはありません。ログインした運用担当者はパスワードを確認してキーを再生成できますが、古いキーは直ちに無効になります。交換が必要なバックエンド環境を一覧にし、計画的に更新してください。1つのシークレット保管先を変えれば、すべての稼働プロセスが自動更新されるとは限りません。
パスワードは安全に保管してください。現在のサービスにはパスワード再設定やGoogleログインがありません。交換後は意図したリクエストで変更した配備先を確認し、正常な取得には課金されることを忘れないでください。変更中もアプリの読み込み表示やエラー案内を実際の状態に合わせます。関連する状態設計と予算のノートは/ja/#field-notesを参照してください。
