/ciba_authz が、宛先のユーザに端末が登録されていないとき HTTP 500 で JSON でない本文を返す

[OsscJpDevInfra]

現象

CIBA の認証リクエスト（POST /ciba_authz）で、login_hint のユーザは存在するが、認証デバイス（DeviceToken）が登録されていないとき、
プッシュ通知の送信（FcmService.SendAsync）で例外になり、処理されずに HTTP 500 になる。

応答の本文は JSON のエラー応答ではない。

• 開発モード（ASPNETCORE_ENVIRONMENT=Development）: UseDeveloperExceptionPage により、例外の平文（System.…Exception: … とスタック トレース）
• それ以外: UseExceptionHandler("/Home/Error") により、HTML のエラー画面

実測（#205 の確認中。net10.0 版、UserStoreType=mem、送信箱なし＝本物の FCM）:
認証サイトを起動し直した直後で、tanaka@gmail.com に端末が未登録の状態のまま、
CIBA の自己テスト（/Home/Saml2OAuth2Starters →「Test FAPI CIBA Profile (FAPI2)」）を実行すると、自己テスト側が次で落ちた。

JsonReaderException: Unexpected character encountered while parsing value: S. Path '', line 0, position 0.
   at MultiPurposeAuthSite.Controllers.HomeController.AssembleFAPICibaProfileStarterAsync()

自己テストは /ciba_authz の応答を JSON として読むので、本文が S で始まっていた（＝例外の平文）と見られる。
サーバ側の例外の型とメッセージは記録していない。 同じユーザで端末を登録した後は、同じ操作が成功した。

環境

バージョン	1st_agent_ph1（d560c1d 時点）
構成要素	MultiPurposeAuthSiteCore / MultiPurposeAuthSite（CommonLibrary の FcmService）
ターゲット	net10.0 で実測。net48 は同じ形のコード（実測していない）
UserStoreType	mem

再現手順

1. 送信箱（FcmOutboxDirectory）を設定せずに認証サイトを起動する（本物の FCM に送る設定。FirebaseServiceAccountKey に実物の鍵）
2. 端末を登録していないユーザを login_hint にして、CIBA の認証リクエストを送る
   （自己テストの宛先は tanaka@gmail.com に固定。起動直後の mem ストアでは、どのユーザも未登録）
3. /ciba_authz が HTTP 500 になる

期待する動作

• 例外を外に出さず、JSON のエラー応答を返す（CIBA Core §13）
• 端末が無いことは、FCM に送る前に判定できる（user.DeviceToken が空）
• FCM への送信そのものが失敗した場合（宛先のトークンが無効など）も、同じく JSON のエラー応答にする
• エラー コードと HTTP ステータスの選び方は、対応時に決める

調べたこと

• OAuth2EndpointController.CibaAuthorizeAsync は、FcmService.GetInstance().SendAsync(user.DeviceToken, "CIBA", …) を try / catch なしで呼んでいる
  • net10.0 : MultiPurposeAuthSiteCore/Controllers/OAuth2EndpointController.cs:815
  • net48 : MultiPurposeAuthSite/Controllers/OAuth2EndpointController.cs:790
• 呼ぶ前に、CibaProvider.Create で CIBA の要求は保存済み。送信に失敗しても、要求は期限（CibaExpireTimeSpanFromSeconds、既定 600 秒）まで残る
• login_hint のユーザが見つからない場合は、400 と unknown_user_id を返すよう直してある（Error responses return HTTP 200 instead of 400 / 401. #196、E2E の RT-196.18）。ユーザは見つかるが端末が無い場合が抜けている
• E2E（test.ps1 -Launch）ではこの失敗は再現しない。 FcmService.SendAsync は、送信箱（テスト用）を使うときは宛先を検証せずにファイルへ書くため。
  テストを足すなら、端末の有無をサーバが送る前に判定する形にする必要がある
• 本番で、宛先のトークンが古い / 無効になったとき（FCM が宛先を拒否したとき）も、同じ経路で 500 になると見られる（実測していない）

利用者への影響

あり。 CIBA を使う RP が、端末を登録していないユーザ（または FCM が宛先を拒否したユーザ）に認証リクエストを送ると、
JSON でない HTTP 500 を受け取る。RP 側はエラー コードで扱いを分けられない。

[OsscJpDevInfra]

29deb89 で修正した。

修正

FcmService.SendAsync の呼び出しに try / catch が無く、例外がそのまま外に出て HTTP 500（JSON でない本文）になっていた。
net10.0 版・net48 版の両方に同じ修正を入れた。

場合	修正前	修正後
ユーザの端末（認証デバイス）が未登録	500 ＋ JSON でない本文	400 ＋ access_denied
プッシュ通知（FCM）の送信に失敗	500 ＋ JSON でない本文	400 ＋ server_error

エラー コードの選び方:

• 端末が未登録：ユーザ自体は login_hint で見つかっているので、unknown_user_id（RT-196.18）ではなく access_denied を使う。承認する手段が無く、要求が成立しないという意味
• 送信の失敗：資格情報の誤り、宛先の拒否、通信障害などをまとめて server_error
• HTTP ステータスは、どちらも既存の GetErrorStatusCode により 400（401 になるのは invalid_client / invalid_token だけ）

実装で気をつけた点:

• 端末の有無は、CibaProvider.Create よりも前に確かめる。 保留中のレコードを作らずに返す
• 送信の失敗は Create の後なので、要求のレコードは期限（CibaExpireTimeSpanFromSeconds、既定 600 秒）まで残る。削除するには provider に新しい処理が必要になるため、この修正には含めていない（コードと ANALYSIS-IdP.md に明記）

検証

検証	結果
ビルド（net48 / net10.0）	エラー 0。警告は 45 / 39 で、修正前と同じ
E2E	224 成功 / 0 失敗 / 2 Skip（226 件中）
追加したテスト RT-210.1	core / netfx の両方で成功

RT-210.1 が通ること自体が、修正の証拠でもある。 修正前なら、期待する 400 ではなく 500 が返っていた。

テストの login_hint には tanaka@gmail.com を使った。
テスト ユーザ（super_tanaka@gmail.com）は EX-8（CIBA）が端末を登録するため、「端末が無い」状態を作れず、実行順にも依存してしまうためである。
tanaka@gmail.com は認証サイトが IsDebug のときに作る利用者で、E2E のどのテストからもサインインしない。

確かめていないこと

• 送信そのものの失敗（server_error）の経路は、動かして確かめていない。 Issue 本文に書いたとおり、test.ps1 -Launch は送信箱を使い、FcmService は宛先を検証せずファイルに書くため、E2E では再現できない。鍵を無効にするなどの手動の確認も行っていない
• 本番で宛先のトークンが無効になった場合（FCM が宛先を拒否する場合）も、同じ catch に入る見込みだが、実測していない

変更したファイル

• MultiPurposeAuthSiteCore/Controllers/OAuth2EndpointController.cs
• MultiPurposeAuthSite/Controllers/OAuth2EndpointController.cs
• Tests/E2ETests/Tests/Issues/HttpStatusTests.cs（RT-210.1）
• Tests/TESTCASES.md（作り直し）
• MultiPurposeAuthSiteCore/ANALYSIS-IdP.md

[OsscJpDevInfra]

この Issue で入れた catch に、原因を記録する 1 行を足しました。 クローズ済みですが、
同じ箇所の変更なのでここに残します。

なぜ足したか

送信の失敗を catch で受け止めたことで、それまで OnException が ACCESS ログに
書いていた内容（何が起きたのか）が失われていました。
利用者への応答は正しくなった一方、運用する側から原因が見えなくなっていた、という状態です。

変更

catch (Exception ex)          // ← 変数を受けるように変更
{
    // **原因は、記録に残す。** 例外を受け止めると、
    //   これまで OnException が ACCESS ログに書いていた内容が失われるため。
    Logging.MyDebugLogForEx(ex);

    // 資格情報の誤り、宛先の拒否、通信障害など。
    err = OAuth2AndOIDCConst.server_error;
    ...

• net48 / net10.0 の両方の OAuth2EndpointController（/ciba_authz）
• 書き先は C:\root\files\resource\Log\ACCESS.YYYY-MM-DD.log
• 同じ考え方を 2FA のコード送信（MobileApp）で、プッシュ通知の送信に失敗すると処理されない例外になる #214（2FA のコード送信）にも入れてあります

確かめたこと

• ビルド : net48 / net10.0 ともエラー 0、警告は変更前と同数（45 / 39）
• E2E の通し : 成功 230 / 失敗 0 / Skip 0

この経路は E2E では踏めません（送信箱を使うので送信が失敗しない）。手でも再現していません —
変更は catch の中の 1 行と using だけです。

利用者への影響

無し。応答（400 と server_error）は変わりません。サーバのログに原因が残るようになるだけです。