11:17

19 апр

написал:

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

Следует сразу отметить, упоминавшийся сайт (назовём его условно example.com) оптимизируют то ли в традициях патологической жадности, то ли разумом правит неудержимость очумелых ручек. Прямо классика жанра: начали со школьника Васи - его просили копнуть здесь и там, ибо так рекомендовал гуру общаги - студент Петя, которому советы нашёптывала баба Маша с колхозного рынка. Через год таких работ уже не понять, кто на сайте что делал и с какого бодуна вот эту пимпочку приделали.

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

Как обнаружили

Запустили браузер
Переключили в режим инкогнито (например, в Chrome надо нажать комбинацию клавиш Ctrl+Shift+N)
Ввели в адресную строку URL сайта - https://example.com

В результате сайт открылся в искажённом виде, притом что на те же действия в стандартном (не инкогнито) режиме сайт открывается и выглядит как надо. Краткое исследование по горячим следам показало следующее:

Эффект наблюдается только при первом входе
Обновление страницы (например Ctrl+F5) приводит вид сайта к нормальному

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

Исследование html-кода страницы показало:

Все абсолютные ссылки имеют вид http://example.com/...
После обновления страницы они принимают правильный вид https://example.com/...

Последствие понятно

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

Причина непонятна

Почему первый заход невидимки сайт видит так, словно человек зашёл по незащищённому протоколу?

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

15:11

19 апр

#

написал:

Есть первый отчёт. Проведена серия опытов, ситуация воспроизводится лишь на сайте с отсутствующим 301 редиректом http -» https, записанным именно в корневом файле .htaccess - программный редирект (из PHP) не прокатывает.

То есть вебсерверный редирект спасает дело, только пока не соображу каким образом - я ведь итак открываю главную страницу сайта уже по протоколу https. А получается запрос, ещё не дойдя внутри сервера до стадии отработки PHP-скрипта, словно слетает на протокол http на каком-то ускользающем от внимания шаге предскриптовой подготовки.

Изучаем дальше...

20:06

19 апр

#

?

написал:

Вообще то https расширение http на порту 443. Uri главной имеет краткий и полный вид.

https://example.com/
http://example.com:443/

Проверь может броузер делает запрос инкогнито по второму виду а конструктор url в твоем шаблоне опускает порт.

10:24

20 апр

#

?

Tangiz написал:

Используйте ссылки без указания схемы - проблемы нет.

<link href="//example.com/style.css" rel="stylesheet">

Стиль загрузится в той же схеме как начальный запрос.

Или относительные ссылки с указанием базы URI.

<base href="//example.com/">
<link href="style.css" rel="stylesheet">

00:14

21 апр

#

написал:

Антон, спасибо, браузер не изменяет протокол в первом инкогнито запросе. Как я ввёл https://.., так браузер и отправил серверу. Это видно в инструментах разработчика (Crtl+Shift+I в хроме) на вкладке Network.

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

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

12:44

21 апр

#

?

написал:

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

17:05

21 апр

#

?

l000trivia написал:

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

Значит искать решение надо предполагая что все тупят.

10:03

22 апр

#

написал:

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

На самом деле обсуждаемый эффект не зависел от запроса в режиме инкогнито. Переданная мне вначале информация спровоцировала поиск строго в направлении невидимочных визитов. Лишь под конец обсуждения я обратил внимание, что эффект повторяется иногда и при стандартном заходе на главную страницу сайта, причём эффект существует минут 15 и исчезает. Так в поле наблюдений попал кеш сайта, который оказался включен с таймером 900 секунд (это как раз 15 минут). Кеш преобразовывал динамические страницы сайта в статические html-снимки, ускоряя тем самым загрузку страниц, на которых пользователи побывали за последние 15 минут.

Сложив все данные вместе (что нет редиректа http/https и значит люди будут попадать кто куда, что кеш пишет и http- и https-снимки в одно хранилище и значит возможны наложения, что снимки устаревают за 15 минут и значит эффект окажется неустойчивым, что ссылки в снимках генерируются абсолютные с протоколом запрощенной страницы), я сообразил в чём дело. Тем более с учётом суточного числа входящих визитов на сайт магазина. Ведь ресурс находится в интернете несколько лет, имеет более тысячи проиндексированных страниц, а объём входящего трафика таков, что каждую минуту на сайте пребывает как минимум 2-3 посетителя (будь то живые люди, поисковые боты или прочие сканеры).

Следовательно раз через раз будет возникать ситуация, когда один визитёр зайдёт на сайт вот так - http://example.com - эта страница закешируется с внутренними абсолютными ссылками на тот же протокол. Остальные визитёры, независимо от используемого ими протокола, 15 минут будут получать http-копию из кеша.

Решение найдено универсальное, с защитой от "все тупят". Мы оборачиваем тегом контентного цензора всё тело общего макета страницы index.tpl, где страница собирается как финальный html-документ. И тегу цензора сообщаем своё требование цензуры, то есть что хотим найти и на что заменить.

{censor change = [ '~https?://example\.com~ui' => '//example.com' ]}
    здесь тело
    общего макета
    страницы
{/censor}