代替フロントエンドオリジン
アプリケーションがドメイン名を変更する段階になり、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 が返されます。