Переадресация на https



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

HTTPS и редиректы

Рассмотрим пример. Допустим, что у нас есть сайт dnsimple.com. Его канонический URL-адрес — https://dnsimple.com. Тем не менее, существует четыре различных способа, с помощью которых можно подключиться к сайту, и нужно обеспечить, чтобы при любом из них пользователь перенаправлялся на https://dnsimple.com:

Настройка htaccess редиректов HTTP на HTTPS часто является причиной путаницы. Не всегда понятно, как правильно обрабатывать через HTTPS редиректы с WWW на не-WWW (или наоборот), и почему для этого нужен сертификат SSL / TLS. Чтобы правильно настроить эти перенаправления, необходимо понять основные принципы обработки запросов HTTPS.


Далее мы рассмотрим, в каком порядке устанавливается соединение по протоколу HTTPS, как происходит обработка HTTP-запросов и настройка редиректов с поддержкой HTTPS.

Поток запроса HTTPS

На приведенном выше изображении показана схема прохождения запросов / ответов HTTPS. Для простоты мы разбили все действия на три фазы:

  1. На первом этапе клиент и сервер договариваются о деталях шифрования, таких как протокол шифрования и набор шифров. Также происходит обмен информацией, необходимой для переключения на защищенное соединение: открытые ключи, сведения о сертификате и т.д. Эта фаза называется «SSL / TLS рукопожатие»;
  2. На втором этапе клиент готовит HTTP-запрос, шифрует его и отправляет на сервер для обработки. Сервер принимает зашифрованный HTTP-запрос, расшифровывает его, обрабатывает и выдает HTTP response (ответ);
  3. На третьем этапе, сервер шифрует ответ и отправляет его клиенту для обработки. Клиент получает зашифрованный HTTP response, дешифрует и обрабатывает его (например, браузер начинает загружать и отображать элементы).

Эта схема потока редиректа с HTTP на HTTPS применима к любому запросу, независимо от содержимого ответа HTTP.

Выше я написал запрос HTTP и ответ HTTP для определенных целей (обратите внимание, что я использовал HTTP, а не HTTPS). С точки зрения содержимого и структуры важно понимать, что HTTPS-запрос — это HTTP-запрос, но передаваемый через защищенное соединение (TLS / SSL).


HTTPS-согласования и редиректы

Одна из самых распространенных ошибок при настройке HTTPS-редиректов — это предположение, что вам не нужен сертификат SSL при переадресации клиента с одного домена на другой.

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

После завершения первого этапа, когда клиент и сервер нашли общий язык (протокол шифрования), они могут начать взаимодействовать друг с другом, используя зашифрованное соединение. В этот момент клиент отправляет HTTP-запрос на сервер, а сервер отправляет HTTP-ответ, содержащий редирект.

Не забывайте, что редирект — это HTTP-ответ с кодом 301 (иногда 302 или 307):

Перед тем, как сделать редирект с HTTPS на HTTP, помните, что, если нужно создать редирект для всего домена, то необходим валидный сертификат SSL для перенаправляемого домена. Для согласования шифрования требуется сертификат SSL, и происходит оно до того, как запрос был обработан, а ответ о редиректе возвращен клиенту.

Если бы все происходило иначе, то редирект бы обрабатывался перед проверкой сертификата SSL. Тогда клиент и сервер были бы вынуждены общаться с помощью обычного HTTP-соединения, которое не шифруется.


Если нужно перенаправить клиента с любой страницы домена https://www.example.com на другую, необходим установленный на сервере валидный сертификат SSL, который распространяется на весь домен www.example.com.

Например, чтобы перенаправить клиента с https://www.example.com на https://example.com, необходимо иметь сертификат, который распространяется на оба или два отдельных сертификата (для каждого хоста соответственно).

Стратегии HTTPS-редиректов

Мы рассмотрели, как обрабатывается редирект с HTTP на HTTPS через htaccess после SSL / TLS согласования. А также выяснили, что для перенаправления клиентов с сайта или страницы на HTTPS нужен валидный сертификат SSL, который охватывает оба домена. Далее я расскажу об общих стратегиях настройки HTTPS-редиректов.

Существует два типа настройки редиректов с HTTPS:

  1. Редирект на уровне сервера;
  2. Редирект на уровне приложений.

Термин сервер обозначает любой сервер, который находится перед веб-приложением и обрабатывает входящий HTTP-запрос. Например, front-end сервер, сервер балансировки нагрузки или единичного приложения.

Термин приложение обозначает веб-приложение, которое может быть либо столь же простым, как PHP-скрипт, либо более сложным, таким как серверное Unicorn-приложение интерпретации Ruby on Rails.

Выполнение HTTPS-редиректов на уровне сервера

Выполнение HTTPS-редиректов на уровне сервера является более предпочтительным. В этом случае сервер, на котором установлен сертификат SSL, принимает зашифрованный HTTP-запрос и возвращает зашифрованный HTTP-ответ о редиректе в соответствии с параметрами конфигурации без соединения с сервером приложения или выполнения кода приложения.


Такой подход является более быстрым, так как сервер может обрабатывать редирект без взаимодействия с приложением. В то же время конфигурация серверов менее гибкая по сравнению с тем, что можно сделать с помощью полноценного языка программирования.
htaccess редирект HTTP на HTTPS на уровне сервера используется для массового перенаправления. Например, редиректа с WWW на не-WWW версию домена с HTTPS (или наоборот).

Следующий фрагмент кода является примером конфигурации Nginx, в котором задается редирект с http://example.com, http://www.example.com и https://www.example.com на https://example.com:

Реализация редиректа на уровне сервера более предпочтительна, но она не всегда осуществима, поскольку вы можете не иметь доступа к конфигурации сервера. Это касается виртуального хостинга или таких платформ, как Heroku, Azure или Google Platform.

Выполнение HTTPS-редиректа на уровне приложений

Когда у вас нет доступа к конфигурации сервера, или логика редиректа является более сложной, необходимо обрабатывать редирект с HTTP на HTTPS на уровне приложений.

Такой подход немного медленнее, потому что сервер должен принять запрос, обработать код приложения (или взаимодействовать с сервером приложений) и вернуть ответ.


То, как выполняется редирект на уровне приложений, зависит от используемого языка программирования и стека. Вот несколько примеров.

Пакет Goland и net/http

Можно использовать http.Redirect.

Ruby on Rails

Можно настроить редирект на уровне маршрутизатора, использовать промежуточное программное обеспечение Rack или метод redirect_to внутри контроллера:

PHP

Используйте функцию header, чтобы отправить HTTP-заголовок перенаправления:

В некоторых случаях это единственно возможный подход. Например, если нужно перенаправить клиентов с WWW на не-WWW версию домена, с HTTPS на Heroku или Azure (или наоборот), то придется указать оба домена в одном приложении, установить сертификат и через условия обрабатывать редирект на уровне приложений.

Альтернативные способы выполнения HTTPS-редиректа

Существует несколько альтернативных способов редиректа с HTTP на HTTPS.

В некоторых ситуациях отсутствует доступ к конфигурации сервера, а платформа, на которой размещен сайт, не позволяет использовать язык программирования. В качестве типичного примера можно привести Amazon S3 для размещения статических сайтов. В этом случае нужно выяснить, предоставляет ли платформа параметры HTTPS-редиректов, которые можно настроить.

Другой вариант заключается в использовании автономного, независимого приложения для редиректов. Например, если нужно перенаправить клиентов с https://alpha.com на https://beta.com. Тогда для домена alpha.com в качестве DNS можно указать другой сервис или сервер, на котором размещен beta.com. А также настроить редирект на уровне сервера или установить приложение, которое будет выступать в качестве редиректора. При этом также необходим валидный сертификат для alpha.com, который будет установлен там, где необходимо осуществить редирект.


Заключение

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

Для создания HTTPS-редиректов требуются дополнительные действия, чтобы перенаправляемый сервер был в состоянии обработать входящие HTTPS-запросы и отправить правильный ответ о редиректе.

Существует много способов обработки URL-редиректов, и, надеюсь, эта статья помогла вам найти подходящий вариант, как сделать редирект с HTTPS на HTTP.

Перевод статьи «Redirects with HTTPS» был подготовлен дружной командой проекта Сайтостроение от А до Я.

www.internet-technologies.ru

Что дает переход с HTTP на HTTPS?

Внедрение нового протокола безопасности для сайта может происходить по трем причинам:


  1. Конфиденциальность. Интернет — это открытая среда, и https здесь защищает коммуникации между сторонами. При отсутствии HTTPS владельцу точки доступа будут доступны приватные данные: кредитные карты (при совершении покупки в интернет-магазине, например).
  2. Целостность. Протокол https гарантирует, что информация будет доставлена адресату в нетронутом виде. Например, владелец Wi-Fi сможет вставлять на сайт «левую» рекламу, изменять внешний вид сайта и сжимать картинки для экономии трафика. Но если на сайте есть HTTPS, то это гарантирует, что сайт не будет изменен.
  3. Подлинность. Сертификат гарантирует, что посещаемый сайт действительно является подлинным.

То есть протокол https гарантирует, что вся информация будет передана целиком и точно по адресу. Никто не сможет изменить информацию при ее передаче. Особенно это актуально для различных интернет-магазинов и сервисов оплаты.

протокол https

Также сертификация оказывает положительное влияние на продвижение сайта в поисковых системах. Поэтому многие вебмастера получают сертификаты безопасности для своих сайтов. Но после получения сталкиваются с проблемой — настройкой. Ведь недостаточно просто получить сертификат, нужно правильно перенаправить весь трафик на новый домен и «рассказать» об этом поисковым системам. Как это сделать?

Подготовка


Перед тем как создать редирект с http на https, необходимо подготовить сайт. Самое первое действие — сделать внутренние ссылки относительными. То есть необходимо убрать вначале ссылки символы «http://». Также можно добавить букву «s» к указанным символам, чтобы все ваши статьи ссылались на версию сайта с протоколом безопасности, но это необходимо делать после окончательного перехода сайта.

htaccess редирект с https на http

Сделать это несложно. Сейчас существует много программ для разных систем управления контентом, которые за пару секунд сделают все ссылки на сайте относительными. Например, для популярной системы Wodpress есть плагин HTTP / HTTPS Remover.

Проверка

После установки сертификата и настройки внешних ссылок желательно проверить, правильно ли «стал» сертификат. Сделать это можно с помощью специального сервиса ssllabs.com. Там нужно вписать доменное имя сайта нажать на кнопку Sabmit, после чего система покажет оценку настройки соединения и даст советы относительно решения возможных проблем. Если параметр Overall Rating будет иметь оценку «A», то значит, все отлично и ваш сертификат безопасности хорош.

Настройка редиректа с http на https

Поисковые системы воспринимают сайты с сертификатом HTTPS и без него как два абсолютно разных сайта. Поэтому настройка редиректа с http на https обязательна. Эта процедура равна смене домена. При этом переадресацию необходимо настроить прямо и важно, чтобы она не содержала промежуточных документов. В противном случае могут образоваться цепочки редиректов, что может запутать поисковые системы. Естественно, это негативно повлияет на восприятие сайта и никакой пользы не принесет.


редирект с http на https в битрикс

Самый простой вариант — редактировать файл htaccess. Редирект с HTTP на HTTPS с помощью этого файла делается в том случае, если сайт размещен на сервере Apache. Необходимо в файле прописать следующие строки:

[…]

RewriteEngine On

RewriteCond %{HTTPS} off

RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

[…]

Можете просто скопировать и вставить в свой файл htaccess. Напомним, он находится в корне вашего сайта и всегда присутствует на сайтах, работающих под управлением Apache.

Прописав данный код, проверьте, действительно ли заработал редирект с http на https. Для этого просто зайдите на любую страницу сайта и посмотрите, перенаправило ли вас на домен с https сертификатом. Если да, то походите по другим страницам.

Теперь, когда робот поисковой системы попадет на ваш сайт, он будет автоматически перенаправлен на версию https. Ему потребуется время, чтобы понять, что к чему и внести эти данные в свой алгоритм. Обычно восприятие перехода и редиректа с http на https у поисковой системы «Яндекс» занимает около месяца, хотя у Google уходит неделя-другая.


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

Впрочем, чаще всего редирект проходит практически безболезненно и быстро. «Яндекс» в течение месяца «склеивает» сайт и его зеркало, и в результате весь трафик возвращается обратно, но уже на новый домен с приставкой https.

Заключение

Рано или поздно переходить на новый протокол безопасности придется. Вскоре это станет одним из ключевых требований поисковых систем, которые просто не будут высоко ранжировать сайты с протоколом http. Так почему бы это не сделать раньше, чем сделают ваши конкуренты? Да, в первое время будет тяжело, и вы, скорее всего, потеряете часть трафика, но в долгосрочной перспективе точно выиграете. По крайней мере, так говорят сами представители поисковых систем. Нет оснований им не верить. И вообще, переход на https — это совершенствование своего сайта с точки зрения безопасности.

fb.ru

Уже ни для кого не секрет, что Гугл и Яндекс начинают выдавать «бонусы» сайтам, у которых установлен сертификат безопасности SSL, и которые начали работать через протокол https. И чтобы корректно настроить редирект с http на https, нужно прописать в .htaccess пару строчек.

Да, строчек действительно две. Но есть определенные нюансы, зависящие от настроек того или иного сервера, заставляющие нас, порой долго, искать в интернете комбинацию этих заветных строк. Ниже я приведу исчерпывающие правила для постраничного редиректа всего сайта с протокола http на https.

Вариант 1

  RewriteCond %{HTTPS} =off   RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [QSA,L]  

Вариант 2

  RewriteCond %{SERVER_PORT} !^443$  RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R,L]  

Вариант 3

  RewriteCond %{ENV:HTTPS} !on  RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]  

Вариант 4

  RewriteCond %{HTTP:X-HTTPS} !1  RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]  

Вариант 5

  RewriteCond %{HTTP:CF-Visitor} '"scheme":"http"'  RewriteRule ^(.*)$ https://www.domain.com/$1 [L] #не забудьте заменить на ваш домен  

Вариант 6

  RewriteCond %{HTTP:X-Forwarded-Protocol} !=https  RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]  

Вариант 7. На одну строчку больше =)

  RewriteCond %{HTTP:X-Forwarded-Proto} !https  RewriteCond %{HTTPS} off  RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]  

Каждый из приведенных выше вариантов нужно прописывать сразу после включения mod_rewrite, а именно — после директивы RewriteEngine On.

alittlebit.ru

Если на своём домене вы используете SSL-сертификат и у вас появилась необходимость переадресовывать все запросы по протоколу HTTP на HTTPS, то добавьте в в начале файла .htaccess следующие строчки:

  RewriteEngine On  RewriteCond %{REQUEST_URI} !^/robots.txt$  RewriteCond %{HTTP:X-Forwarded-proto} !^https$  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Для правильной работы вашего сайта по протоколу https необходимо для элементов, которые открываются по небезопасному протоколу http, заменить ссылки.
Например, если у вас указан путь к определенному контенту таким образом: http://ваш-домен.ru/banner.gif, то нужно поменять адрес на https://ваш-домен.ru/banner.gif
Для элементов, которые загружаются с внешних серверов, также необходимо изменить ссылки. При этом важно чтобы сайт, где расположен элемент, также использовал валидный SSL сертификат.

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

Если вы используете CMS Joomla, то отредактируйте файл configuration.php и пропишите правильные значения в следующих строчках:
было:

  public $live_site ='http://ваш-домен.ru';

стало:

  public $live_site ='https://ваш-домен.ru';

было:

  public $force_ssl = '0';

стало:

  public $force_ssl = '1';

 

Если вы используете WordPress, то зайдите в админку своего сайта, откройте раздел "Настройки" -> "Общие" и в полях "Адрес сайта" и "Адрес WordPress" поменяйте протокол на https.

Если вы используете CMS 1C-Bitrix, то настройте https-соединение по инструкции от разработчиков.

В OpenCart откройте панель управления вашим магазином и перейдите в раздел "Система" -> "Настройки"  на вкладке Сервер выберите Использовать SSL: Да. В файле config.php, который расположен в корневой папке магазина и в директории /admin, замените все ссылки http:// на https://.

В Drupal (до 8 версии) откройте файл /sites/default/settings.php и добавьте следующую строчку:

  $conf['https'] = TRUE;

mchost.ru

Что такое редирект с http на https?

Очень важно, чтобы после перехода на защищенный протокол все ссылки Вашего сайта работали по https. В этом и заключается весь смысл надежности передачи данных. В ином случае браузер будет выдавать ошибки, что на сайте присутствует смешанный контент. Это означает, что некоторые данные (часто изображения, js-скрипты, css-стили) будут передаваться по незащищенному протоколу (http). Отметим, что от корректного перехода на https зависит сохранность данных всех Ваших пользователей.

Как выполнить редирект с http на https в WordPress?

Весь процесс перевода WordPress-сайта на https описывать не будем, так как это было подробно рассмотрено в одной из наших статей. Остановимся лишь на последнем его этапе — корректной переадресации всех http-ссылок сайта на https.

Наиболее простым и надежным способом является использование плагина Clearfy Pro, который без каких-либо проблем гарантирует правильную переадресацию с http на https для всех разделов и элементов Вашего сайта. Для этого достаточно в админ-части перейти Clearfy Pro и на вкладке SEO активировать настройку Редирект с http на https.

Страница настроек плагина Clearfy Pro

Рассмотрим также и другие, менее удобные, способы переадресации на https, которые имеют один существенный недостаток — предоставляются в виде дополнительных плагинов.

Способ 1. Плагин Easy HTTPS Redirection

Easy HTTPS Redirection — отдельный плагин для осуществления редиректа с http на https. После его установки и активации следует включить процесс редиректа. Для этого необходимо перейти в раздел Настройки -> HTTPS Redirection и активировать настройку Enable automatic redirection to the «HTTPS», после чего нажать кнопку Сохранить изменения.

Страница настроек плагина Easy HTTPS Redirection

Способ 2. Плагин Force HTTPS

Force HTTPS — плагин, который сразу после установки и активации будет выполнять переадресацию всех страниц Вашего сайта на защищенный протокол https. В настройках не нуждается. Следует отметить, что после его активации все разделы сайта, включая админ-часть, будут доступны через https. Для этого перед его установкой необходимо еще раз удостовериться о наличии SSL-сертификата для домена Вашего сайта.

wpschool.ru

#user 'user10' virtual host 'example.com' configuration file
server {
    
server_name example.com www.example.com;
    
charset off;
    
disable_symlinks if_not_owner from=$root_path;
    
index index.html index.php;
    
root $root_path;
    
set $root_path /var/www/user10/data/www/example.com;
    
ssi on;
    
access_log /var/www/httpd-logs/example.com.access.log ;
    
error_log /var/www/httpd-logs/example.com.error.log notice;
    include /
etc/nginx/vhosts-includes/*.conf;
    include /etc/nginx/vhosts-resources/user10/*.conf;
    location / {
        location ~* ^.+.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ {
            try_files $uri $uri/ @fallback;
        }
        location / {
            try_files /does_not_exists @fallback;
        }
        location ~ [^/].ph(pd*|tml)$ {
            try_files /does_not_exists @fallback;
        }
    }
    location @fallback {
        error_log /dev/null crit;
        proxy_pass http://127.0.0.1:8080;
        proxy_redirect http://127.0.0.1:8080 /;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Secret 123123;
    }
    listen 77.77.77.77:80;
}
server {
    server_name example.com www.example.com;
    charset off;
    disable_symlinks if_not_owner from=$root_path;
    index index.html index.php;
    root $root_path;
    set $root_path /var/www/user10/data/www/example.com;
    ssi on;
    access_log /var/www/httpd-logs/example.com.access.log ;
    error_log /var/www/httpd-logs/example.com.error.log notice;
    include /etc/nginx/vhosts-includes/*.conf;
    include /etc/nginx/vhosts-resources/user10/*.conf;
    location / {
        location ~* ^.+.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ {
            try_files $uri $uri/ @fallback;
        }
        location / {
            try_files /does_not_exists @fallback;
        }
        location ~ [^/].ph(pd*|tml)$ {
            try_files /does_not_exists @fallback;
        }
    }
    location @fallback {
        error_log /dev/null crit;
        proxy_pass http://127.0.0.1:8080;
        proxy_redirect http://127.0.0.1:8080 /;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Secret 123123;
    }
    listen 77.77.77.77:443;
    ssl on;
    ssl_certificate /var/www/httpd-cert/user10/example.com.crt;
    ssl_certificate_key /var/www/httpd-cert/user10/example.com.key;

forum.ispsystem.ru

Редиректы

Редирект наверное лучше всего настроить через .htaccess, путем вставки такой конструкции перед правилами WordPress. А лучше перед всеми правилами, т.е. в самое начало файла:

# SSL: 301 redirect to https from http <IfModule mod_rewrite.c> 	RewriteEngine On 	RewriteCond %{SERVER_PORT} !^443$ 	RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L] </IfModule>

Еще вариант:

RewriteCond %{HTTP:X-HTTPS} !1 RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Еще вариант:

RewriteCond %{THE_REQUEST} ^[A-Z]{3,9} /(.*) HTTP/ [NC] RewriteCond %{HTTPS} off [NC] RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [R=301,QSA,L]

Тут важно, что устанавливается 301 редирект, в сети посмотрел эту тему, кое-где его не используют, а он нужен!

Также, можно установить редирект в PHP, вместе с редиректом c .htaccess. Пригодится, если по какой-то причине редирект с апача слетит, чтобы PHP был на подстраховке…

## redirect с http на https add_action('init', 'http_to_https_redirect'); function http_to_https_redirect(){ 	if( is_ssl() ) return;  	if ( 0 === strpos($_SERVER['REQUEST_URI'], 'http') ) 		wp_redirect( set_url_scheme( $_SERVER['REQUEST_URI'], 'https' ), 301 ); 	else 		wp_redirect( 'https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'], 301 );  	exit; }

Изменение URL в контенте

В сети видел предложения заменять http на https прямо в базе данных. Я думаю это не лучшее решение, потому что возможно в будущем вы откажетесь от SSL и тогда нужно будет все менять обратно… Поэтому лучше делать замену на лету, таким кодом (он быстрый):

add_filter('the_content', 'replace_url_to_https', 30); function replace_url_to_https( $text ){ 	$text = preg_replace('~http(://(?:www.)?'. preg_quote($_SERVER['HTTP_HOST']) .')~', 'https1', $text ); 	return $text; }

Как вы, наверное, понимаете функцию replace_url_to_https() можно будет применить к любому тексту, где нужно заменить текст http://ваш-сайт.ru/* текст на текст https://ваш-сайт.ru/* текст. Она меняет все без разбора, будь то картинки или что-то еще, но только для URL относящихся к текущему домену…

Изменение URL других ссылок

Вообще WordPress автоматически подстраивается под https протокол текущей страницы и все ссылки должны измениться автоматом. Поэтому нет необходимости изменять даже протоколы в ссылках: URL сайта и URL WordPress (в настройках). Их протокол меняется налету…

Но если этого не произошло (протокол страницы https, но в ней есть ссылки http), то для смены протокола отдельных ссылок в WP есть функция set_url_scheme().

Пример:

echo set_url_scheme( 'http://site.ru/foo', 'https' ); // https://site.ru/foo

Корневая функция на основе которой ставиться протокол всех ссылок — это is_ssl(). Влияя на нее мы может влиять на все ссылки, при условии, что они жестко не прописаны в HTML, а выводятся через различные функции WordPress. Например, следующим кодом мы можем, жестко указать протокол https для всех ссылок на странице, даже если протокол страницы http:

$_SERVER[ 'HTTPS' ] = 'on'; // чтобы is_ssl() всегда возвращала true

Вызвать такой код нужно как можно раньше, до подключения плагинов. И наверное перед его вызовом нужно сделать какие-то проверки. Этот код — это просто пример…

Плагины

Как обычно, можно использовать плагины (я их не пробовал)…

Easy HTTPS Redirection — заглянул в код, вроде бы как раз то что вам нужно…

WordPress HTTPS (SSL) — вроде тоже хорош, правда не обновляется уже давно. Он, как я понял, заменяет все ссылки во всем HTML документе, работает как комбаин: много лишних операций, но может это и нужно, потому что удобно…

wp-kama.ru

В переводе этого документа описываются шаги, которые необходимо предпринять для перевода вашего сайта с HTTP на HTTPS. Шаги можно выполнять с любой скоростью – либо всё за день, либо один шаг за месяц. Главное, делать это последовательно.

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

Для кого предназначена эта инструкция?

Администраторы, разработчики и их менеджеры – те, кто обслуживает сайты, в данный момент использующие только HTTP-соединение. При этом они желают мигрировать, или хотя бы поддерживать, HTTPS.

1: Получение и установка сертификатов

Если вы ещё не получили сертификаты – необходимо выбрать поставщика, и купить сертификат. Сейчас есть пара возможностей даже получить сертификаты бесплатно – например, их выдаёт контора RapidSSL. Кроме того, в 2015 году Mozilla обещают сделать бесплатную выдачу сертификатов.

Скопируйте полученные сертификаты на ваши фронтенд-сервера куда-нибудь в /etc/ssl (Linux / Unix) или в приемлемое место для IIS (Windows).

2: Включение HTTPS на сервере

Здесь надо определиться:

— либо использовать хостинг по IP, когда у каждого хоста свой IP
— либо отказаться от поддержки пользователей, которые используют IE на Windows XP или Android с версией менее 2.3

На большинстве сайтов настроен виртуальный хостинг, который работает с доменными именами (name-based) – это экономит IP-адреса и вообще более удобно. Проблема в том, что IE и древний Android не понимают Server Name Indication (SNI), а это критично для работы HTTPS при name-based хостинге.

Когда-нибудь все эти клиенты вымрут. Вы можете отслеживать количество таких клиентов и решить, нужно их поддерживать или нет.

Далее настройте поддержку сертификатов, которые вы получили, в вашем веб-сервере. Конфигурацию сервера можно создать через Mozilla configuration generator или SSLMate.

Если у вас много хостов и поддоменов – кажды из них потребует установки подходящего сертификата. Для поддоменов лучше использовать сертификаты с маской типа *.domain.ru

В идеале, вам необходимо переадресовывать все запросы к HTTP на HTTPS и использовать Strict Transport Security (см. шаги 4 и 5)

После этого проверьте работу сайта с новыми настройками при помощи инструмента Qualys SSL Server Test. Добейтесь того, чтобы сайт заслуживал оценки A или A+.

3: Сделайте все внутренние ссылки относительными

Теперь, когда ваш сайт работает и на HTTP и на HTTPS, вам нужно добиться его работы вне зависимости от протокола. Может возникнуть проблема смешанных протоколов – когда на странице, которую грузят через HTTPS, указаны ресурсы, доступные по HTTP. В этом случае браузер предупредит пользователя, что защита, предоставляемая HTTPS, перестала работать на 100%.

По умолчанию многие браузеры вообще не будут загружать смешанный контент. Если это будут скрипты или стили, страница перестанет работать. К слову, включать в страницу, загруженную по HTTP, контент, доступный через HTTPS, можно без проблем.

Проблема эта решается заменой полных линков на относительные. Вместо такого:

<h1>Welcome To Example.com</h1> <script src="http://example.com/jquery.js"></script> <link rel="stylesheet" href="http://assets.example.com/style.css"/> <img src="http://img.example.com/logo.png"/> <p>Read this nice <a href="http://example.com/2014/12/24/">new post on cats!</a></p> <p>Check out this <a href="http://foo.com/">other cool site.</a></p> 

надо сделать такое:

<h1>Welcome To Example.com</h1> <script src="//example.com/jquery.js"></script> <link rel="stylesheet" href="//assets.example.com/style.css"/> <img src="1450829848287066165294"/> <p>Read this nice <a href="//example.com/2014/12/24/">new post on cats!</a></p> <p>Check out this <a href="http://foo.com/">other cool site.</a></p> 

или такое:

<h1>Welcome To Example.com</h1> <script src="/jquery.js"></script> <link rel="stylesheet" href="//assets.example.com/style.css"/> <img src="1450829848287066165294"/> <p>Read this nice <a href="/2014/12/24/">new post on cats!</a></p> <p>Check out this <a href="http://foo.com/">other cool site.</a></p> 

Все линки должны быть относительными, и чем относительнее, тем лучше. По возможности надо убрать протокол (//example.com) или домен (/jquery.js).

Лучше делать это при помощи скриптов, и не забыть про контент, который может находиться в базах данных, скриптах, стилях, правилах редиректа, тегах link. Проверить сайт на наличие смешанного контента можно скриптом от Bram van Damme.

Естественно, в ссылках на другие сайты протоколы менять не нужно.

Если в вашем сайте используются скрипты и другие ресурсы от третьих лиц, например CDN, jquery.com, у вас есть 2 варианта:

— также использовать URL без указания протокола
— скопируйте эти ресурсы к себе на сервер. Это в любом случае надёжнее

4: Переадресация с HTTP на HTTPS

Установите тег

<link rel="canonical" href="https://…"/>  

на ваших страницах. Это поможет поисковым системам лучше ориентироваться у вас.

Большинство веб-серверов предлагают простые решения для редиректа. Инструкции для Apache и для nginx. Используйте код 301 (Moved Permanently).

5: Включите Strict Transport Security и Secure Cookies

На этом шаге вы уже ограничиваете доступ к сайту только для HTTPS. Strict Transport Security сообщает клиентам, что им надо соединяться с сайтом только по HTTPS, даже если ссылка идёт на http://. Это помогает против атак типа SSL Stripping и экономит время на переадресациях из четвёртого шага.

Убедитесь, что ваши TLS-настройки реально работают – например, сертификат не просрочен. На этом шаге любая ошибка будет блокировать доступ к сайту.

Включите HTTP Strict Transport Security посредством заголовка Strict-Transport-Security. На этой странице есть ссылки на инструкции для разных серверов.

Примечание: max-age измеряется в секундах. Начните с небольших величин и по мере роста уверенности в работе сайта увеличивайте их.

Для того, чтобы клиенты всегда отправляли куки по защищённому каналу, включите флаг Secure для куков. На этой странице есть инструкция для этого.

Проблемы с миграцией

habr.com


You May Also Like

About the Author: admind

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.