No referrer when downgrade что значит

Полезный META тег Referrer Policy для HTTPS сайта.

Самые популярные товары с Али по лучшей цене здесь

Полезный META тег Referrer Policy для HTTPS сайта.

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

Поисковые гиганты уровня Гугла откровенно лоббируют https протокол документов в своей поисковой выдаче. Браузеры в адресной строке стебутся и глумятся, как могут, над «небезопасными» сайтами. В SEO нише все новости подряд про преференции сайтов под SSL сертификатами, и так далее.

И добро бы, будь это просто новостной фон.
Прочли и забыли.

Но на деле наши хостеры уже давно и всем подряд выдают SSL-сертификаты типа DV (domain validation), причём насильно. Пусть самого начального уровня (бесплатные), и на короткий срок, но автоматически продлеваемые. А это уже не досужие разговоры, и с этим следует как-то определиться.

Наблюдения за Гуглом.

Местный автор поначалу относился к SSL вакханалии полностью индифферентно. Но, раз того требует великий Гугл, нехай страницы авторизации и всяких там форм обратной связи всегда будут под https протоколом, а все остальные — как уж в адресной строке сложилось. Хоть так, хоть этак, ибо используемый автором движок позволяет в конфигах задать URL морды сайта в зависимости от того, как протокол написан в адресной строке текущего юзера:

‘base’ => ‘http’ .((isset( $_SERVER [ ‘HTTPS’ ]) and $_SERVER [ ‘HTTPS’ ]== ‘on’ ) ? ‘s’ : » ). ‘://lasto.com/’ ,

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

Никто не предполагал, что далее случится странное.

Местный автор заметил, что спустя некоторое время индексирующий бот Гугла, обходя его сайт, видел на странице авторизации все ссылки в навигации в протоколе https (в соответствии с логикой, указанной выше PHP оператором, все внутренние ссылки строятся относительно морды сайта, заданной вот так), и последовательно заменял в выдаче у всех этих документов в URL-е протокол на безопасный.

Понятно, что произошло дальше.

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

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

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

Кстати, Яндекс ничего подобного делать не стал, и по запросу «site:lasto.com» выдавал документы строго в http протоколе. При этом никакой директивы Host в файле роботса прописано не было, в Яндекс.Вебмастере местный автор никогда даже не регистрировался, и зеркало сайта или предпочтительный протокол в нём не настраивал.

Перевод сайта на HTTPS протокол.

Поскольку всякий вебмастер приучен сразу и правильно понимать намёки великого Гугла, который из каких-то соображений однозначно выбрал «правильный» протокол, было бы логично теперь избавиться от одной из версий ресурса в пользу другой. Что делается явной записью в конфиге вместо «странного» PHP оператора:

Всё, морда сайта у нас теперь задана во всей её конкретности, не допускает вольного толкования, и осталось лишь принудительно перекинуть http трафик в https протокол. Что делается силами .htaccess файла, и в простейшем случае выглядит так:

RewriteEngine On
RewriteCond % < SERVER_PORT >!^ 443 $
RewriteRule .* https : //%% [R=301,L]

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

Ну и можно ещё заглянуть в файл robots.txt, если он у Вас есть. Специально для Яндекса там обычно прописана директива «Host:», в которой принято указывать зеркало сайта (есть www. в имени домена, или нет). Этой же директивой задаётся и желаемый протокол — видимо, иным образом донести до Яндекса своё отношение к выбору протокола сайта не получается.

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

А теперь неприятное. Недостатки HTTPS протокола.

Замедление загрузки сайта.

Нужно быть готовым к тому, что «обычный» трафик ходит заметно быстрее, чем «защищённый». Ибо во втором случае есть дополнительное обращение к третьей стороне (поставщик SSL сертификата), что занимает лишнее время перед тем, как сайт начнёт загружаться. И эта задержка заметна на глаз.

Ошибка SSL: Потеря доступа к сайту.

Есть определённая вероятность того, что бесплатные начальные сертификаты (обычно от «Let’s Encrypt»), выпускаемые всего на три месяца, могут быть не продлены вовремя. В результате сайт не открывается, на экране ошибка доступа по причине недействительности SSL сертификата. Что печалит.

Отзыв SSL сертификата, Роскомнадзор.

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

Такое уже разок было (Роскомнадзор заблокировал Comodo, а заодно и себя, ибо сам в тот момент имел SSL сертификат от Comodo). И много раз ещё повторится в разных вариантах.

Причём ситуация намного хуже, чем может показаться.

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

Но легче и проще ни в какой суд вообще не обращаться, а выпустить (и навязать его всем пользователям) какой-нибудь «Яндекс-браузер», который, как и любой другой браузер, тоже имеет право отзывать SSL сертификат как отдельного сайта, так и вообще все сертификаты, выпущенные любым удостоверяющим центром.

Пока такого ещё ни разу не делалось, но в нужный момент Вы в одночасье лишитесь доступа к «неправильным» сайтам — браузер со стрингами на логотипе впаривается всеми силами и каждому подряд не просто так.

Наличие у сайта SSL сертификата искажает статистику исходящего с него трафика. Вот тут будьте внимательны.

Все мы помним, как Гугл поломал детектирование поисковых запросов, просто переведя свой поиск на https протокол. Ибо наши сайты в большинстве своём тогда были «беззащитные», а им по уставу не положено видеть параметры в URL-ах ссылающегося на них сайта. А именно в тех параметрах прописан поисковый запрос.

Самый последний пункт нам, как вебмастерам, очень интересен. И, видимо, настала пора познакомиться с такой сущностью, как Referrer Policy. Собственно, это и является истинной темой нашей сегодняшней встречи.

МЕТА тег «Referrer Policy»

Это относительно свеженький стандарт, от 2017 года. Но уже популярный.
На языке первоисточника доступен тут.

Встраивается в сайт простейшим образом, в виде тега секции header

meta name = «referrer» content = «*» >

Вместо звёздочки можно и нужно писать разные сущности, и в зависимости от вписанной сущности внешний сайт, на который ссылается страница с таким вот МЕТА тегом в коде, либо будет знать в точности источник трафика, либо только его домен, либо не узнает вообще ничего.

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

no-referrer

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

Трудно представить, зачем такой вариант вообще предусмотрен. Видимо, для истинных параноиков. Либо когда вебмастер вообще не анализирует перемещение посетителей по ресурсу, и не желает сообщать внешним сайтам, с какого именно URL-а к нему переходит серфер — для внешнего сайта это будет так называемый «букмарковый трафик».

Этот вариант МЕТА тега совершенно обязательно размещать на всех страницах всевозможных систем тикетов, особенно бездарно сконструированных. Местный автор часто видит в своей статистике переходы с тикетовых систем разных хостеров, причём при клике в линк можно читать этот чужой тикет, без всякой авторизации вообще.

Это, конечно, эпический фейл и фиаско. Если уж скрипт системы тикетов написан идиотом, хотя бы добавьте данный МЕТА-тег на все страницы тикетов в указанном выше виде. Что, конечно, совсем не поможет, если браузер клиента старый, и этот тег не разумеет.

no-referrer-when-downgrade

Реферер не передаётся от https к http сайту, и передаётся во всех остальных случаях. Причём это справедливо и для варианта общения сайта с самим собой, но в разных протоколах.

С большой степенью вероятности отсутствие данного МЕТА-тега вообще приведёт к такому же эффекту.

same-origin

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

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

origin

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

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

Так что не будет хорошей идеей употреблять сей МЕТА тег именно в таком написании. Да и метрики откажутся работать — внутренние переходы не отследить.

strict-origin

То же самое, но уже играет роль иерархия протоколов. При переходе с https сайта на http (в том числе и в пределах одного домена) реферер не передаётся. Во всех остальных случаях в качестве реферера фигурирует морда сайта, а не его конкретный документ.

origin-when-cross-origin

Только при переходе внутри сайта реферером является ссылающаяся страница, во всех остальных случаях это будет морда сайта.

То же самое, что и четвёртый вариант, но тут метрика должна быть работоспособна.

strict-origin-when-cross-origin

Более строгий вариант- то же, что и предыдущее, но если ссылающийся сайт в https протоколе, а прилинкованный — в http, то реферер вообще пропадает.

unsafe-url

Реферер передаётся в любом случае.

Как видим, по дефолту (когда мы переводим свой сайт с http на https протокол) у нас автоматически реализуется второй вариант, а сайты в http протоколе, на которые мы по-прежнему ссылаемся, перестают воспринимать нас в качестве источника трафика — в реферере это просто не отражено.

Конечно, это ненормальная ситуация.

Поэтому всё-таки имеет смысл вписать в шаблон дизайна сайта МЕТА-тег в самом последнем варианте его написания. Чтобы любой сайт имел возможность наблюдать в своей статистике все ссылающиеся на него ресурсы в рамках максимально демократичной процедуры «unsafe-url Referrer Policy».

Примечание.

Естественно, реферер (информация об источнике трафика) переносится от сайта к сайту силами браузера посетителя, и браузер либо знаком с «Referrer Policy», либо не понимает, чего от него хочет хитрый МЕТА-тег.

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

Рекомендации.

Как видим, МЕТА-тег «Referrer Policy» хоть и не отличается разнообразием вариантов (их номенклатуру можно было бы и расширить), тем не менее позволяет работать с реферерами по-разному, в зависимости от протокола сайта. Это ценное свойство, особенно если можно открыть сайт хоть «безопасно», хоть «не безопасно».

Более полезна способность тега ограничить передачу реферера либо совсем, либо только внешним сайтам. Этим следует обязательно пользоваться на страницах, требующих секьюритетности — всякие там личные кабинеты, тикеты, и тому подобное.

Правда, если сервисы написаны по уму (например, URL всех страниц сервиса одинаковый, ибо данные передаются исключительно через POST, а GET параметры не используются вообще), тегу особо и нечего защищать. Разве что сам факт наличия исходящей ссылки.

Тем не менее, тег однозначно полезный, знать про него надо.
Как и вовсю пользоваться им.

Другие статьи категории «Вебмастеру на заметку»

Видимо, случилось прекращение роста в доменной зоне RU.

Какие элементы сайта сегодня можно потерять.

Антипопингуйство сегодня, и один из вариантов борьбы с ним.

№ 1 Referrer Policy применительно к движку местного автора.

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

Если вдруг окажется, что он не определён, или не совпадает с ожидаемым, форма тупо не сработает. Да ещё и будет ругаться.

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

Зато определённый интерес представляет политика «same-origin»

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

№ 2 Директива Хост для Яндекса не нужна

20 марта сего года Яндекс в блоге для вебмастеров сообщил, что отказывается от директивы «Host» в пользу 301 редиректа, и разрешил удалить её из роботс. Так окончились пятнадцать лет борьбы со спецификацией.

Спасибо за информацию.
Даже и не знал 🙂

Воистину, всё, что «хочет от тебя странного», должно быть проигнорировано просто на автомате.

Источник