Перейти к содержимому

Переезд на HTTPS - контент, база, интеграции

Переводим работающий сайт на защищённый протокол целиком: правило перехода здесь только первый шаг. Сертификат к этому моменту уже выпущен, и сайт отвечает по обоим протоколам сразу.

Решение

Опись до переключения

Считаем, сколько адресов придётся править:

Окно терминала
grep -rn 'http://example.com' local/templates/ bitrix/templates/ | wc -l
mysql -e "SELECT COUNT(*) FROM b_iblock_element \
WHERE DETAIL_TEXT LIKE '%http://example.com%'" sitemanager0
# файлы и база правятся разными инструментами, поэтому считают их по отдельности

Опись занимает полчаса и сразу задаёт порядок работ на переключении. Сайт с сотней абсолютных адресов в описаниях товаров переключают вместе с заменой.

Правило перехода и исключения

Ставим переход внутри блока адреса:

server {
listen 80;
server_name example.com;
location = /bitrix/admin/1c_exchange.php {
proxy_pass http://127.0.0.1:8090; # точка обмена остаётся на прежнем протоколе
# незащищённый адрес закрывают по адресу отправителя: allow и deny рядом
}
location / {
return 301 https://example.com$request_uri;
}
}

Директива return в блоке server отрабатывает раньше выбора адреса и глотает исключения. Учётные системы старых версий защищённое соединение не устанавливают, и точку обмена оставляют на прежнем протоколе.

Протокол запроса на стороне ядра

Смотрим, каким видит запрос само ядро:

use Bitrix\Main\Context;
$request = Context::getCurrent()->getRequest();
var_dump($request->isHttps()); // признак защищённого соединения
var_dump($request->getHttpHost()); // домен берётся из запроса, а не из настроек

Метод isHttps читает признак соединения у веб-сервера, а не у самого сайта. За балансировщиком шифрование заканчивается раньше сайта, признак приходит пустым, и переход зацикливается.

Смешанный контент

Ищем незащищённые адреса в готовой странице:

Окно терминала
curl -s https://example.com/ | grep -oE '(src|href)="http://[^"]+' | sort -u
grep -rn 'http://example.com' local/templates/main/header.php | head
# заголовки ответа веб-сервера смешанный контент не лечат, правят только источник

Скрипты и фоновые запросы браузер блокирует целиком, а картинки только помечает замком. Абсолютные адреса приходят из шаблона сайта, включаемых областей и сохранённых текстов инфоблоков.

Адреса в базе и в настройках сайта

Меняем протокол только у своего домена:

SELECT COUNT(*) FROM b_iblock_element WHERE DETAIL_TEXT LIKE '%http://example.com/%';
UPDATE b_iblock_element
SET DETAIL_TEXT = REPLACE(DETAIL_TEXT, 'http://example.com/', 'https://example.com/');
-- перед заменой снимают резервную копию: откатить такой запрос уже нечем

Замена подстроки без имени домена ломает ссылки на чужие сайты и документы. То же правило повторяют для полей анонса и для строковых свойств элементов.

Проверяем адрес сайта в настройках:

use Bitrix\Main\Config\Option;
use Bitrix\Main\SiteTable;
echo Option::get('main', 'server_name'), "\n"; // адрес для писем и фоновых заданий
print_r(SiteTable::getList(['select' => ['LID', 'SERVER_NAME']])->fetchAll());
// при мультисайтовости поле адреса проверяют у каждого сайта по отдельности

В обоих полях лежит домен без протокола, и переключение их не задевает. Протокол ссылки ядро подставляет по текущему запросу, а почтовый шаблон хранит адрес целиком.

Что перепроверить после переключения

Платёжные системы держат адрес возврата и адрес уведомления в своём личном кабинете. Постоянный переход теряет тело запроса, и уведомление об оплате до заказа не доходит.

Обмен с учётной системой проверяют отдельным запуском, а не по журналу ошибок. Карту сайта и композитный кэш пересобирают принудительно: обе эти вещи хранят готовые адреса страниц.

Проверка результата

Смотрим цепочку, кэш и карту сайта:

Окно терминала
curl -sIL -o /dev/null -w '%{num_redirects} %{url_effective}\n' http://example.com/catalog/
curl -sI https://example.com/ | grep -i 'x-bitrix-composite'
curl -s https://example.com/sitemap.xml | grep -c 'http://example.com'

Один переход вместо трёх и нулевой счётчик в карте сайта закрывают проверку. Постоянный код ответа ставят последним, когда исключения для служебных адресов уже проверены временным переходом.

Типичные проблемы

Страница открылась по https, а замок перечёркнут.

Логотип и часть картинок шаблона записаны абсолютным адресом со старым протоколом прямо в вёрстке. Такую страницу браузер помечает как смешанную даже при полностью исправном сертификате.

Кнопка «Купить» перестала работать, в консоли Mixed Content.

Компонент собирает адрес фонового запроса по незащищённому адресу из своих собственных параметров. Такой запрос браузер блокирует целиком, и товар в корзину покупателя не попадает.

После переключения встал обмен с учётной системой.

Общее правило перехода поймало заодно и служебный адрес точки обмена с учётной системой. Учётные системы старых версий защищённое соединение не устанавливают и получают в ответ переход.

Исключение прописано, а обмен по-прежнему уходит на переход.

Веб-сервер не перечитал конфигурацию после правки файла и работает по прежним правилам. Правку применяют перезагрузкой конфигурации и сразу проверяют отдельным запросом, а не глазами.

Часть страниц открывается по прежнему протоколу без перехода.

Эти страницы отдаёт композитный кэш ещё до попадания запроса в обработчик PHP. Кэш сбрасывают сразу после переключения, иначе старые адреса живут в нём сутками.

Частые вопросы

Перевели сайт на https, а в консоли Mixed Content. Что править?

Источник адреса, а не настройки веб-сервера. Абсолютные адреса ищут в шаблоне сайта, во включаемых областях и в сохранённых текстах инфоблоков, затем меняют протокол в каждом из этих мест.

Можно ли отключить переход на https для точки обмена с 1С?

Да, отдельным блоком адреса до общего правила. На уровне блока сервера исключение не работает: директива перехода отрабатывает раньше выбора адреса и применяется ко всем запросам сразу.

Надо ли менять адрес сайта в настройках после перехода?

В полях адреса лежит домен без протокола, и трогать их не нужно. Протокол правят там, где он записан целиком: в почтовых шаблонах, в текстах инфоблоков и в настройках внешних сервисов.

Хватит ли редиректа вместо замены адресов в базе?

Для посетителя хватит, для страницы - нет. Картинка с незащищённым адресом внутри защищённой страницы получает пометку браузера, а фоновый запрос блокируется до всякого перехода.

Просядут ли позиции после перехода на защищённый протокол?

Просадка на пару недель бывает, если переход отдаётся временным кодом или собирается цепочкой из трёх шагов. Одно правило с постоянным кодом ответа переносит адреса без потерь.

Смежное

Первоисточник