Мультипаспорт в Битрикс: авторизация по ID пользователя только для локальной отладки

Смысл приёма

При поддержке нескольких копий сайта или тестового стенда удобно не вводить пароль каждый раз, а один раз перейти по короткой ссылке и оказаться «в нужном» аккаунте. В старых заметках этот паттерн называют условным «мультипаспортом»: вы задаёте ID пользователя и немедленно вызываете штатную авторизацию ядра.

Исторический пример в духе оригинала выглядит так:

<?php
require($_SERVER['DOCUMENT_ROOT'] . '/bitrix/header.php');

if (!empty($_GET['userID'])) {
    $userId = (int)$_GET['userID'];
    global $USER;
    $USER->Authorize($userId);
}
?>

На публичном или боевом контуре такой файл — прямой бэкдор: любой, кто угадает или переберёт ID, получит вашу или чужую сессию без пароля.

Обязательные ограничения

• Использовать только на машине разработчика или за VPN с жёстким ACL: проверять 127.0.0.1, локальную подсеть Docker или вашу статическую IP.
• Связать включение страницы с константой окружения, например BITRIX_ENV === 'local' или defined('BX_DEBUG') && BX_DEBUG, которая никогда не попадает в продакшен-билды.
• Не класть скрипт в репозиторий с включёнными проверками «на всякий случай»: лучше отдельный необходимость-файл в /local/tools/ и запрет через .gitignore, если команда этого не любит держать в VCS вообще.

Вариант с узкой фильтрацией запроса

Минимум — ограничить адрес источника и отказать всем остальным без выдачи формы или лога:

<?php
require($_SERVER['DOCUMENT_ROOT'] . '/bitrix/header.php');

$trusted = ($_SERVER['REMOTE_ADDR'] ?? '') === '127.0.0.1'
    || ($_SERVER['REMOTE_ADDR'] ?? '') === '::1';

if (!$trusted) {
    @define('ERROR_404', 'Y');
    require $_SERVER['DOCUMENT_ROOT'] . '/404.php';
    exit;
}

$userId = (int)($_GET['switch_user'] ?? 0);
if ($userId > 0) {
    global $USER;
    $USER->Authorize($userId);
}
?>
<form method="get" action="">
    <label>ID пользователя <input type="number" name="switch_user" min="1"/></label>
    <button type="submit">Войти</button>
</form>
<?php require $_SERVER['DOCUMENT_ROOT'] . '/bitrix/footer.php'; ?>

Метод по умолчанию привязывает авторизацию к текущей сессии; при обновлениях ядра сверьтесь со штатным описанием CUser::Authorize в вашей ветке.

Почему не GET без POST и сессии

Открытый GET-параметр попадает в лог балансировщика, историю браузера и рефереры внешних ресурсов. Если всё-таки оставляете форму методом GET ради простоты, держите скрипт строго вне продакшена. Более терпимо к журналированию использовать POST, sessid через bitrix_sessid_post() и проверку check_bitrix_sessid() — даже локально это снимает случайную активацию по клику из офисного чата со ссылкой.

Цивилизованные альтернативы

• Стандартный вход под другим пользователем из админки («Авторизоваться как пользователь», права администратора).
• Одноразовые ссылки и обмен ключами между стендами — через штатный или партнёрский функционал, а не голый числовой ID.

В продуктовом режиме «мультипаспорт» по описанному принципу не должен существовать: его заменяют контролируемые процедуры поддержки.