注：これはセキュリティの観点からは望ましい動作ですが、ユーザーに这种情况が発生した場合は UX を向上させることができます
ユーザーが U2F トークンを登録している場合、登録後のサイトのホスト名が変更されていると、そのトークンは機能しません。
ただし、Discourse にはその情報が保存されていないため、ホスト名が変更されたことが原因である可能性について、ユーザーへのフィードバックはありません。ユーザーがその理由を理解していない場合、混乱を招く可能性があります。
この場合の改善案として、以下の画面で対応を検討できます：
- 「セキュリティキーで認証」を無効化する
- 「このアカウントにはセキュリティキーが登録されていますが、リクエスト先（www.example.com）のホスト名用ではありません」といったメッセージを表示する
考慮事項：
- 上記を実施する場合、UserSecurityKey テーブル内で古いホスト名を新しいホスト名に再マッピングしないようにする必要があります
「いいね！」 6
ええ、ドメイン名変更の場合に対応する文言をここに加える必要がありますね、@sam。たぶん、単なる文言の更新で、フッターに免責事項のようなものを置く感じでしょうか？
「いいね！」 1
martin
(Martin Brennan)
4
これは少し厄介かもしれません。ホスト名はセキュリティキーテーブル内の公開キーに格納されていると思うからです（この件については以前から手が離れており、間違っている可能性もあります）。この問題を UI に引き継ぎ、ボタンを無効にしてメッセージを表示するには、少し工夫が必要です。また、これは登録されているすべてのセキュリティキーのホスト名が誤っている場合のみ表示され、一つでも一致すればユーザーは問題ありません。
関連する話ですが、2fa security key breaks when migrating to custom domain - #6 by balboah の修正も行う必要があります。ホスト名を変更する際には、既存のセキュリティキーは実質的に無効になるため、それらをすべて無効にするべきだと考えています。そのため、このトピックも自分に割り当てます。
「いいね！」 1
pfaffman
(Jay Pfaffman)
6
私はよく、本番環境から異なるホスト名を持つステージングサイトにデータベースを復元します。無効なキーをすべて無効化し、管理者にリセットを要求する機能が備わると素晴らしいのですが（責任あるユーザーはバックアップキーを設定しているため、実際にはあまり役立たないかもしれませんが 
）。
「いいね！」 1
）。