代替フロントエンドオリジン
アプリケーションがドメイン名を変更する段階になり、Internet Identity で認証を行っている場合、ユーザーがこれまでと同じ Principal をシームレスに使用できるようにしたいと思うことでしょう。この機能をサポートするために、このガイドを使用して代替フロントエンドオリジン用にアプリケーションを設定することができます。

以下のような場合に、このガイドが必要になるはずです:
<canister-id>.ic0.appからカスタムドメインへ移動する- ユーザーに 
/ではなく/loginでログインするように要求する raw.ic0.appを使用するユーザーをサポートする- 組織内の複数のアプリが同じ Principal を使用するように設定する
 - その他
 
制約
現在、最大 10 の代替オリジンをリストアップすることができます。
II は、これらの代替を構成するオリジンが、Certified Assets を使用する Canister で ホストされている場合にのみ、この仕様に従います。
詳細については、Internet Identity Spec を参照してください。
代替オリジンを設定する
この例では、A と B という2つのドメインを用意します。A が正規のオリジンで、B が代替ドメインとなります。このモデルを説明するために、https://internetcomputer.org と https://hwvjt-wqaaa-aaaam-qadra-cai.ic0.app の両方でホストされているこの Web サイトを考えてみましょう。
この例では、A が Canister ID、つまり、https://hwvjt-wqaaa-aaaam-qadra-cai.ic0.app になります。
B は代替オリジン、すなわち、https://internetcomputer.org です。
オリジンをリストする
オリジン A に対して、Internet Identity に B が有効なオリジンであることを伝えるファイルを提供する必要があります。この例では、設定ファイルを src/assets に配置することにします。アセット Canister が現在 dist フォルダからアセットをデプロイするように設定されている場合、Canister の sources を更新して両方を含めるようにしてください。
"source": [
    "dist",
    "src/assets"
]
src/assets の中に .well-known フォルダを作り、 ii-alternative-origins という名前のファイルを追加します。
ファイル名は ii-alternative-origins とし、拡張子はつけないこと。中のコンテンツは JSON でフォーマットされていますが、ファイルの末尾に .json を付けないようにしてください。
このファイルの中で、B の代替オリジンをリストアップしてください。このようになります:
{
  "alternativeOrigins": ["https://internetcomputer.org"]
}
オリジンから末尾のスラッシュやクエリパラメータを削除していることを確認してください。
あなたのプロジェクトは次のようなっているはずです:
├── dfx.json
├── src
│   ├── assets
│   │   ├── .well-known
│   │   │   └── ii-alternative-origins
アセット Canister を設定する
.well-knownのドット構文は通常、ファイルシステムによって “隠しファイル" として扱われるため、ドキュメントをアップロードするためにはアセット Canister を設定することが必要です。アセット Canister を設定するには、.ic-assets.json というファイルを新規に作成します。.ic-assets.json は Canister の sources にリストされているディレクトリの中に置く必要があります。新しいファイル一覧はこのようになります。
├── dfx.json
├── package.json
├── src
│   ├── assets
│   │   ├── .ic-assets.json
│   │   ├── .well-known
│   │   │   └── ii-alternative-origins
次に、.well-known ディレクトリが含まれるように下記のように設定します。
[
  {
    "match": ".well-known",
    "ignore": false
  },
  {
    "match": ".well-known/ii-alternative-origins",
    "headers": {
      "Access-Control-Allow-Origin": "*",
      "Content-Type": "application/json"
    },
    "ignore": false
  }
]
これには、.well-known ディレクトリを無視しない一般的なルールと、ii-alternative-origins をアクセス制御とコンテントタイプヘッダー付きで配信するルールが含まれます。
あとは、Canister を配備するだけです。これ以降、オリジン B から認証を試みると、A を使用しているときと同じ Principal が返されます。