Bitrix\Main\Request — D7-обёртка над глобальными
массивами $_GET, $_POST,
$_SERVER с встроенной базовой защитой от опасных
символов. Разберём, чем это лучше прямого обращения к суперглобалам
и какие ограничения стоит знать при работе с ней.
Получение объекта запроса
<?php
use Bitrix\Main\Context;
$request = Context::getCurrent()->getRequest();
$id = $request->get('id');
$action = $request->getPost('action');
Context::getCurrent() — правильный способ получить
текущий запрос из любого места кода D7, включая обработчики событий
и компоненты, без обращения к глобальным переменным напрямую.
Разница между get(), getPost() и getQuery()
<?php
$request->getQuery('id'); // только из $_GET
$request->getPost('id'); // только из $_POST
$request->get('id'); // из GET и POST одновременно
Метод get() без уточнения ищет значение и в GET,
и в POST — удобно для универсального кода, но менее предсказуемо
для форм, где важно точно знать источник данных (например, значение
из GET-параметра адресной строки не должно случайно подменить
значение из отправленной формы).
Нужна помощь с Битрикс?
Встроенная фильтрация
<?php
$request->get('search'); // XSS-опасные последовательности уже удалены
Request автоматически применяет базовую фильтрацию
от типичных XSS-паттернов ко всем значениям, полученным через её
методы, — в отличие от прямого обращения к $_GET
и $_POST, где такой фильтрации нет вовсе. Однако эта
фильтрация — не полноценная защита: она не заменяет экранирование
вывода (htmlspecialchars) в шаблоне и не защищает
от SQL-инъекций, которые предотвращаются параметризованными
запросами, а не фильтрацией входных данных.
Проверка метода запроса
<?php
if ($request->isPost()) {
// обработка отправки формы
}
if ($request->isAjaxRequest()) {
// запрос пришёл через XMLHttpRequest / fetch с соответствующим заголовком
}
Получение заголовков и IP-адреса
<?php
$userAgent = $request->getUserAgent();
$ip = $request->getRemoteAddress();
$referer = $request->getHeader('Referer');
getRemoteAddress() учитывает настройки прокси
и заголовки вроде X-Forwarded-For, если они настроены
на уровне сервера, — прямое чтение $_SERVER['REMOTE_ADDR']
за обратным прокси или CDN обычно возвращает адрес прокси, а не
реального посетителя.
Работа с файлами загрузки
<?php
$file = $request->getFile('document');
if ($file) {
$fileArray = $file->getUploadedFile();
// передать в CFile::SaveFile или Bitrix\Main\FileTable
}
Почему не стоит смешивать Request и прямое обращение к $_POST
Смешанное использование $request->getPost() в одном
месте кода и $_POST напрямую в другом — источник
путаницы, особенно если фильтрация значений где-то применена,
а где-то нет. Единообразное использование объекта запроса во всём
D7-коде делает поведение предсказуемым и упрощает последующий поиск
всех мест, где обрабатываются входные данные, при аудите
безопасности.
Частые ошибки
- Расчёт на встроенную фильтрацию как на полную защиту. Базовая фильтрация XSS не заменяет экранирование вывода и параметризацию SQL-запросов.
- Использование get() там, где важен конкретный источник. Значение из GET неожиданно подменяет ожидаемое значение из POST.
- Прямое чтение $_SERVER['REMOTE_ADDR'] за прокси. Возвращает адрес прокси-сервера вместо реального посетителя.
- Смешивание Request и суперглобальных массивов в одном проекте. Непредсказуемое поведение фильтрации между разными участками кода.
Итог
Bitrix\Main\Request даёт единый интерфейс к данным
запроса с базовой встроенной фильтрацией и корректным определением
реального IP-адреса за прокси. Она не заменяет полноценную защиту
от XSS и SQL-инъекций на выводе и в запросах к базе, но делает
работу с входными данными единообразной и предсказуемой по всему
D7-коду проекта.
