[GRDM-57850] Fix encoding error for Japanese Characters in IdP Authentication Attributes

[ndnhat1]

Purpose

Resolve encoding error in displaying authentication information received from IdP

Changes

Fixed the handling of character encoding for IdP attributes to properly display Japanese characters.

QA Notes

Documentation

Side Effects

Ticket

57850

[yacchin1205]

views.pyおよびテストは問題ないように思います。 fix_encoding_errors.py について、以下の2種類の課題があると思いますので、ご検討ください。

• エンコーディング検出の問題: HTTP_AUTH_DISPLAYNAME の補正は Shibboleth/WSGI ヘッダ由来という入力経路が明確なので妥当だと思います。一方で、このスクリプトは DB 内の任意文字列(OSFUser.fullname, given_name, jobs, schools, social, UserExtendedData.data などを横断... Shibboleth直接？由来以外のものを含む)を対象に、文字列の見た目から「UTF-8 bytes が Latin-1 として保存された値」かどうかを推定して修復しようとしています。一般論として、この判定を安全に自動化する手段はないと思います(多分にheuristic)。特に errors='replace' による partial result を --include-unrecoverable で DB に書き戻せる設計は、データ破損リスクがあります。まずは候補 CSV の出力に留め、DB 更新は人手確認済みのoriginal_value / suggested_value を明示入力する二段階方式にする方が安全だと思います。
• エラー処理の問題: DB 修復スクリプトとしては、想定外の状態を 'N/A' や空 dict/list にフォールバックして処理継続している点が気になります。例えば user._id は修復結果の追跡キーなので、欠損時に 'N/A' として CSV に流すと監査・再照合が難しくなります。また record.user 不在、OSFUser/UserExtendedData.DoesNotExist、getattr(..., None)、except Exception での握り潰しなどは、不変条件違反や実装ミスを隠してしまいます。修復対象データの追跡性を保つためにも、想定外の状態では fail fast するか、事前検証で明示的に除外する方がよいと思います。

[hidefumi-moritani]

@yacchin1205

ご指摘ありがとうございます。Migration Script を以下の方針で見直します。

まとめ

• --include-unrecoverable オプションを廃止し、partial 復元結果の DB 書き戻し経路を廃止
• フォールバック値による処理継続・例外握り潰しを廃止し、データ不備検知時は即時停止する Fail Fast 方針を採用
• DB 更新は、Migration Script から直接行わず、CSV ファイル経由の二段階方式に変更

1. partial 結果の DB 書き戻し廃止

--include-unrecoverable オプションを廃止し、partial 復元結果（欠損バイトを含む復元）の DB 書き戻し経路を廃止いたします。

2. エラー処理の Fail Fast 化

ご指摘の「フォールバック値による処理継続」「例外握り潰し」を廃止し、データ不備や想定外の状態を検知した時点で例外をスローして即時停止する設計に変更いたします。

具体的な変更内容：

• 'N/A' / None 等のフォールバック値による処理継続を廃止し、明示的に例外をスロー
• except Exception / DoesNotExist 等の例外握り潰しを廃止し、例外発生時はログ出力の上で即時停止

3. CSV ファイル経由の二段階反映

ご提案の「DB 更新は人手確認済みの original_value / suggested_value を明示入力する二段階方式」を採用いたします。

運用フロー

1. Migration Script で文字化け候補レコードを CSV ファイルに出力（DB 更新は行わない）。出力 CSV には文字コード逆変換結果（suggested_fix）が含まれます
2. 出力 CSV を管理者が確認し、必要に応じて行の削除や値の修正を行います
3. 編集済 CSV を入力として Migration Script が DB に反映

CSV インポート時のバリデーション

以下のバリデーションを実施し、エラー検知時は即時停止（処理全体をロールバック）します。

• ヘッダー / カラム数の整合性確認
• 必須項目（user._id 等）の空チェック
• suggested_fix（修正値）の値の妥当性は、DB への保存時に Django モデルの制約（フィールド長制約等）で自動検証
• original_value と現在の DB 実データの一致チェック（エクスポートからインポートまでの間に DB が更新されていないかの整合性確認）

整合性チェックで不一致を検知した場合

エクスポート以降に対象データが他の操作（ユーザのログインや Web 画面からの編集等）で更新された可能性があるため、処理を停止します。最新の状態で CSV を再エクスポートいただいた上で再実行する運用となります。