Webフォルダソースの追加

Webフォルダソースは、公開可能なウェブサイト上の既存のアセットフォルダ、通常はウェブサイトの既存のアセットフォルダに接続します。 認証が必要な場合、認証ヘッダーをオリジンに送信するようにWebフォルダソースを設定できます。

Webフォルダソースの設定

1. imgixダッシュボードのソースページ (opens in a new tab)に移動し、新規ソースボタンをクリックします。

2. メディアの保存方法は？のラジオオプションからWebフォルダを選択します。

   

3. WebフォルダソースのベースURLを指定します - imgixがフェッチできる有効なWeb URLを使用する必要があります。

   

   注意: 配信性を向上させるために、リダイレクトが行われないパスを使用してください。例えば、ドメインがhttpからhttpsへトラフィックをリダイレクトする場合、ベースURLの設定でhttpsを使用する必要があります。

4. アセットのベースURLとして使用するサブドメインの名前を入力します。

   

6. ステップ＃3で保存ボタンをクリックして、ソースをデプロイキューに入れます。

   

受け入れ可能なベースURL

お使いのベースURLはimgixがアクセス可能である必要があります。WebフォルダURLがimgixのアセットへのアクセスをブロックする場合や、アセットにアクセスするためのログインが必要な場合、オリジンからアセットを取得できません。

Webフォルダオリジンにファイアウォールがある場合は、imgixユーザーエージェントを許可リストに追加してください。

さらに、WebフォルダURLは有効であり、RFC仕様に従う必要があります。ベースURLの検証には次のルールを使用します：

• 各レベル（ドットで分割）は最大63文字まで含めることができます。
• ドメイン名全体は最大127レベルまでです。
• ドメイン名全体のテキスト表現の長さは253文字を超えてはなりません。
• 各ラベルは文字、数字、ハイフンで構成されることができます。
• ラベルはハイフンで始まるか終わることはできません。
• トップレベルドメイン（拡張子）はすべて数字ではいけません

オリジンへのリクエスト認証の設定

オプションとして、imgixがオリジンからアセットを安全に取得できるように認証を設定することができます。使用できるオプションには、基本認証、カスタムヘッダー認証、およびリクエストごとの署名があります。

設定後、imgixはオリジンへのリクエストに追加のヘッダーを含めます。これらのヘッダー値は、サービスからのリクエストを認証するために使用され、ダッシュボードで設定できます。

Webフォルダソースでオリジン認証が設定されている場合の例として送信されるヘッダーは次のとおりです:

{
  "headers": {
    "Authorization": "Basic <base_64_encoded_username_password>",
    "X-Imgix-Signature": "<your_signature>",
    "X-Imgix-Signature-Host": "<origin_host>",
    "X-Imgix-Signature-Request-Id": "<request_id>",
    "X-Imgix-Signature-Timestamp": "<timestamp>"
  }
}

• Basic Auth - Username: 基本認証用のユーザー名。コロン記号(:)やRFC 5234規格 (opens in a new tab)に記載されている制御文字を含むことはできません。
• Basic Auth - Password: 基本認証用のパスワード。コロン記号(:)や制御文字を含むことはできません。
• Request Handshake: 最大256文字を受け入れます。カスタムヘッダー認証を参照してください。
• Request Signing Key: 最大32文字のラテン1文字を受け入れる文字列です。bashコマンドを使用して生成することができます。例: openssl rand -base64 24。サーバーに送信されるヘッダーとして署名を生成するために使用されます。リクエストごとの署名を参照してください。

基本認証

基本認証は、imgixサービスからオリジンへのリクエストを認証する最も簡単な方法です。ユーザー名を指定することにより、imgixはオリジンへのリクエストに基本認証ヘッダーを含めます。リクエストの例は次のとおりです:

"Authorization": "Basic dXNlcm5hbWVfZXhhbXBsZTpwYXNzd29yZF9leGFtcGxl"

例では、dXNlcm5hbWVfZXhhbXBsZTpwYXNzd29yZF9leGFtcGxlはBase64でデコードされるとusername_example:password_exampleになります。

ユーザー名とパスワードの値にはコロンを含めることはできず、基本認証ヘッダーでユーザー名とパスワードを区切るためにコロンが予約されています。また、ユーザー名とパスワードには制御文字を含めることはできません。

カスタムヘッダー値/ハンドシェイクトークン

別の認証方法として、ソース設定にrequest_handshake値を設定できます。request_handshake値はX-Imgix-Origin-Secretというヘッダーとしてオリジンに送信され、最大256文字の文字列を受け入れます。これを使用して、リクエストのオリジンにこのヘッダー/値が存在するかどうかを確認することにより、カスタム認証を設定できます。

このヘッダー値でオリジンに送信されるリクエストは次のようになります:

"X-Imgix-Origin-Secret": "custom_origin_secret_value"

リクエストごとの署名

さらに安全な方法としてリクエストごとの署名があります。これを使用すると、request_signing_keyを使用してオリジンへのリクエストを認証できます。これは最も安全な方法ですが、資格情報を復号化して認証するためにimgixの外部で追加の設定が必要です。

request_signing_key値は32文字のラテン1文字を受け入れます。

これにより、秘密の32文字の値が取得され、imgixが送信するリクエストに対してHMAC-SHA256ダイジェスト署名が生成され、オリジンで認証を確認するために使用されます。

設定されると、imgixはオリジンへのリクエストに以下のヘッダーを含めます:

• X-Imgix-Signature-Timestamp: Unixエポック秒
• X-Imgix-Signature-Request-Id: imgixが生成するリクエストごとのID
• X-Imgix-Signature: バージョンタグ（v1）に続いて、シークレットキーを使用して署名されたメッセージ<RequestId>.<Timestamp>のHMAC-SHA256ダイジェスト（すべて大文字の16進数値）

imgixから送信されるリクエストの例は次のとおりです:

"X-Imgix-Signature": "v1,23BDF62CBF5121A808C415B952956E52DDF7E733C7EA97F0D8F814BEDC237F9F",
"X-Imgix-Signature-Host": "www.examplesite.com",
"X-Imgix-Signature-Request-Id": "a3c1f07cd7f9dc17fe9352dd391aa052f90ba51df95231f09fadc760b8457564",
"X-Imgix-Signature-Timestamp": "1709332618"

詳細設定

カスタムドメイン、デフォルト、キャッシュTTLオプションの設定に関する情報は、アドバンスドソース設定を参照してください。