リクエスト ¶

アプリケーションへのリクエストは、リクエストパラメータ、HTTPヘッダ、クッキーなどの情報を提供する yii\web\Request オブジェクトとして表現されます。特定のリクエストについて、対応するリクエストオブジェクトには、デフォルトでは yii\web\Request のインスタンスである request アプリケーションコンポーネント を介してアクセスできます。このセクションでは、アプリケーションでこのコンポーネントを使用する方法について説明します。

リクエストパラメータ ¶

リクエストパラメータを取得するには、request コンポーネントの get() メソッドと post() メソッドを呼び出すことができます。これらのメソッドは、それぞれ $_GET と $_POST の値を返します。例を以下に示します。

$request = Yii::$app->request;

$get = $request->get();
// equivalent to: $get = $_GET;

$id = $request->get('id');
// equivalent to: $id = isset($_GET['id']) ? $_GET['id'] : null;

$id = $request->get('id', 1);
// equivalent to: $id = isset($_GET['id']) ? $_GET['id'] : 1;

$post = $request->post();
// equivalent to: $post = $_POST;

$name = $request->post('name');
// equivalent to: $name = isset($_POST['name']) ? $_POST['name'] : null;

$name = $request->post('name', '');
// equivalent to: $name = isset($_POST['name']) ? $_POST['name'] : '';

情報: リクエストパラメータを取得するために $_GET および $_POST に直接アクセスする代わりに、上記のように request コンポーネント経由で取得することをお勧めします。これにより、偽のリクエストデータを持つモックリクエストコンポーネントを作成できるため、テストの記述が容易になります。

RESTful API を実装する場合、PUT、PATCH、その他のリクエストメソッド を介して送信されたパラメータを取得する必要があることがよくあります。これらのパラメータは、yii\web\Request::getBodyParam() メソッドを呼び出すことで取得できます。例を以下に示します。

$request = Yii::$app->request;

// returns all parameters
$params = $request->bodyParams;

// returns the parameter "id"
$param = $request->getBodyParam('id');

情報: GET パラメータとは異なり、POST、PUT、PATCH などを介して送信されるパラメータはリクエストボディで送信されます。 request コンポーネントは、上記の方法でアクセスしたときにこれらのパラメータを解析します。 yii\web\Request::$parsers プロパティを構成することで、これらのパラメータの解析方法をカスタマイズできます。

リクエストメソッド ¶

現在のリクエストで使用されているHTTPメソッドは、式 Yii::$app->request->method を介して取得できます。現在のメソッドが特定のタイプであるかどうかを確認するためのブール値のプロパティのセットも提供されています。例を以下に示します。

$request = Yii::$app->request;

if ($request->isAjax) { /* the request is an AJAX request */ }
if ($request->isGet)  { /* the request method is GET */ }
if ($request->isPost) { /* the request method is POST */ }
if ($request->isPut)  { /* the request method is PUT */ }

リクエストURL ¶

request コンポーネントは、現在リクエストされているURLを検査するさまざまな方法を提供します。

リクエストされているURLが https://example.com/admin/index.php/product?id=100 であると仮定すると、このURLのさまざまな部分を次の表に示すように取得できます。

• url: ホスト情報部分を除いたURLである /admin/index.php/product?id=100 を返します。
• absoluteUrl: https://example.com/admin/index.php/product?id=100 を返します。これはホスト情報部分を含む URL 全体です。
• hostInfo: https://example.com を返します。これは URL のホスト情報部分です。
• pathInfo: /product を返します。これはエントリスクリプトの後、クエスチョンマーク (クエリ文字列) の前の部分です。
• queryString: id=100 を返します。これはクエスチョンマークの後の部分です。
• baseUrl: /admin を返します。これはホスト情報の後、エントリスクリプト名の前の部分です。
• scriptUrl: /admin/index.php を返します。これはパス情報とクエリ文字列を含まない URL です。
• serverName: example.com を返します。これは URL のホスト名です。
• serverPort: 80 を返します。これは Web サーバーが使用するポートです。

HTTP ヘッダー ¶

yii\web\Request::$headers プロパティによって返されるヘッダーコレクションを通じて、HTTP ヘッダー情報を取得できます。例:

// $headers is an object of yii\web\HeaderCollection 
$headers = Yii::$app->request->headers;

// returns the Accept header value
$accept = $headers->get('Accept');

if ($headers->has('User-Agent')) { /* there is User-Agent header */ }

request コンポーネントは、以下を含む、よく使われるヘッダーへの迅速なアクセスもサポートしています。

• userAgent: User-Agent ヘッダーの値を返します。
• contentType: リクエストボディ内のデータの MIME タイプを示す Content-Type ヘッダーの値を返します。
• acceptableContentTypes: ユーザーが受け入れ可能なコンテンツ MIME タイプを返します。返されるタイプは、品質スコアによって順序付けられます。最もスコアの高いタイプが最初に返されます。
• acceptableLanguages: ユーザーが受け入れ可能な言語を返します。返される言語は、優先度レベルによって順序付けられます。最初の要素が最も優先される言語を表します。

アプリケーションが複数の言語をサポートしており、エンドユーザーが最も優先する言語でページを表示したい場合は、言語ネゴシエーションメソッド yii\web\Request::getPreferredLanguage() を使用できます。このメソッドは、アプリケーションでサポートされている言語のリストを受け取り、それらをacceptableLanguagesと比較して、最も適切な言語を返します。

ヒント: ContentNegotiator フィルターを使用して、レスポンスで使用すべきコンテンツタイプと言語を動的に決定することもできます。このフィルターは、上記で説明したプロパティとメソッドに基づいてコンテンツネゴシエーションを実装します。

クライアント情報 ¶

クライアントマシンのホスト名と IP アドレスは、それぞれ userHost と userIP を通じて取得できます。例:

$userHost = Yii::$app->request->userHost;
$userIP = Yii::$app->request->userIP;

信頼できるプロキシとヘッダー ¶

前のセクションでは、ホストや IP アドレスなどのユーザー情報を取得する方法を見てきました。これは、Web サイトの提供に単一の Web サーバーが使用される通常のセットアップでは、すぐに機能します。ただし、Yii アプリケーションがリバースプロキシの背後で実行されている場合は、追加の設定をしてこの情報を取得する必要があります。直接のクライアントはプロキシであり、ユーザーの IP アドレスはプロキシによって設定されたヘッダーを介して Yii アプリケーションに渡されるためです。

プロキシを明示的に信頼しない限り、プロキシによって提供されたヘッダーを盲目的に信頼しないでください。2.0.13 以降、Yii は request コンポーネントの trustedHosts、secureHeaders、ipHeaders、secureProtocolHeaders および portHeaders (2.0.46 以降) プロパティを介した信頼できるプロキシの設定をサポートしています。

以下は、10.0.2.0/24 IP ネットワーク内にあるリバースプロキシの配列の背後で実行されるアプリケーションのリクエスト設定です。

'request' => [
    // ...
    'trustedHosts' => [
        '10.0.2.0/24',
    ],
],

IP はデフォルトでプロキシによって X-Forwarded-For ヘッダーで送信され、プロトコル (http または https) は X-Forwarded-Proto で送信されます。

プロキシが異なるヘッダーを使用している場合は、リクエスト設定を使用してこれらを調整できます。例:

'request' => [
    // ...
    'trustedHosts' => [
        '10.0.2.0/24' => [
            'X-ProxyUser-Ip',
            'Front-End-Https',
        ],
    ],
    'secureHeaders' => [
        'X-Forwarded-For',
        'X-Forwarded-Host',
        'X-Forwarded-Proto',
        'X-Forwarded-Port',
        'X-Proxy-User-Ip',
        'Front-End-Https',
    ],
    'ipHeaders' => [
        'X-Proxy-User-Ip',
    ],
    'secureProtocolHeaders' => [
        'Front-End-Https' => ['on']
    ],
],

上記の設定では、リクエストがプロキシによって行われた場合、secureHeaders にリストされているすべてのヘッダーは、X-ProxyUser-Ip および Front-End-Https ヘッダーを除いて、リクエストからフィルタリングされます。その場合、前者は ipHeaders で構成されたようにユーザー IP を取得するために使用され、後者は yii\web\Request::getIsSecureConnection() の結果を決定するために使用されます。

2.0.31 以降、RFC 7239 Forwarded ヘッダーがサポートされています。これを有効にするには、ヘッダー名を secureHeaders に追加する必要があります。プロキシがそれを設定していることを確認してください。そうでない場合、エンドユーザーは IP とプロトコルをスプーフィングできる可能性があります。

既に解決済みのユーザー IP ¶

ユーザーの IP アドレスが Yii アプリケーションの前に解決されている場合 (例: ngx_http_realip_module など)、request コンポーネントは次の構成で正しく動作します。

'request' => [
    // ...
    'trustedHosts' => [
        '0.0.0.0/0',
    ],
    'ipHeaders' => [], 
],

この場合、userIP の値は $_SERVER['REMOTE_ADDR'] と等しくなります。また、HTTP ヘッダーから解決されるプロパティも正しく機能します (例: yii\web\Request::getIsSecureConnection())。

警告: trustedHosts=['0.0.0.0/0'] 設定は、すべての IP が信頼されていることを前提としています。