Плагин «HTTPS Detect» (обновление 09.03.2014)

Описание

Плагин отслеживает схему, использованную пользователем для входа на сайт (HTTP или HTTPS) и корректирует значения "$config['path']['root']['web']" и "$config['path']['static']['root']", ссылки на JS и CSS файлы, ссылки на аватары и фотографии пользователей, ссылки на изображения в фотосете, а также ссылки на изображения и видео в тексте топиков, комментариев и т.д.

Тестовый сайт: http://ls.wasja.info, https://ls.wasja.info

GitHub: github.com/wasja1982/livestreet_httpsdetect

Настройка

Настройка плагина осуществляется редактированием файла "/plugins/httpsdetect/config/config.php".

Поддерживаемые директивы:
1) $config['correct_js_link'] — Обрабатывать ссылки на JS-файлы. По умолчанию включено (true).

2) $config['correct_css_link'] — Обрабатывать ссылки на CSS-файлы. По умолчанию включено (true).

3) $config['correct_img_src'] — Обрабатывать ссылки на изображения в тексте. По умолчанию включено (true).

4) $config['correct_video_src'] — Обрабатывать ссылки на видео в тексте. По умолчанию включено (true).

5) $config['separate_path'] — Использовать отдельный путь для хранения JS и CSS файлов HTTPS протокола. По умолчанию отключено (false).

Обработка ссылок на изображения и видео в тексте осуществляется:
  • в тексте топиков;
  • в тексте комментариев;
  • в тексте статических страниц (плагин «Static Page»);
  • в описании блога;
  • в сообщениях;
  • в записях на стене;
  • в информации пользователей «О себе».

Установка

1. Скопировать плагин в каталог /plugins/
2. Через панель управления плагинами (/admin/plugins/) запустить его активацию.

При использовании перед Apache в качестве frontend сервера nginx необходимо добавить в его конфигурацию строку
proxy_set_header X-Forwarded-Proto $scheme;


Известные проблемы

1. При заходе по HTTPS не загружаются файлы в фотосете (с использование SWF-загрузчика). Причина в самом загрузчике, который не работает по HTTPS протоколу. Решение: не использовать загрузчик.

2. При использовании шаблона «Synio» идет загрузка Google-шрифтов по HTTP протоколу. Решение:
— в файле "/templates/skin/synio/header.tpl" удалить строку
<link href='http://fonts.googleapis.com/css?family=PT+Sans:400,700&subset=latin,cyrillic' rel='stylesheet' type='text/css'>

— в файле "/templates/skin/synio/settings/config/config.php" добавить в массив
$config['head']['default']['css'] = array(
...
);

строку
"http://fonts.googleapis.com/css?family=PT+Sans:400,700&subset=latin,cyrillic" => array('merge'=>false),


3. При использовании плагина «Gravatar» аватары всегда загружаются по HTTP протоколу. Решение: заменить в файле "/plugins/gravatar/classes/modules/gravatar/entity/User.entity.class.php" строку
return "http://www.gravatar.com/avatar/".md5(strtolower($this->getMail())).".png?size=".$iSize;

на строку
return (Config::Get('plugin.httpsdetect.https') ? "https" : "http") . "://www.gravatar.com/avatar/".md5(strtolower($this->getMail())).".png?size=".$iSize;


Изменения

1.0.1 (09.03.2014)
— Исправлены ошибки.
— Добавлен параметр $config['correct_video_src'] — Обрабатывать ссылки на видео в тексте.
— Добавлена коррекция параметра конфигурации 'path.static.root'.
— Добавлена поддержка плагина «Domain for static».

102 комментария

avatar
github.com/livestreet/livestreet/issues/371
Эту проблему надо решать в корне, а не отдельным плагином, но хорошо что начали мыслить в этом направлении. Плюс заслуженный.
avatar
Потому как проблема более сильного характера чем вы описали и в ней нет ничего нового.
livestreet.ru/
avatar
Дело не только в статике. Например, все изображения, залитые во время работы по http, вызывают кое-какие вопросы со стороны браузера во время работы по https (Google Chrome ругается).
avatar
Разумеется. Любой браузер будет ругаться на обращение по HTTP из HTTPS сессии. Это нарушение безопасности.

Вообще корень проблемы в том как LS работает с изображениями. Хранить, конечно, нужно относительные пути — это бы сняло целую пачку проблем. И с CDN, и с переходом на другой домен и с вот с HTTPS. в Alto вроде продвинулись в этом направлении дальше.
avatar
Разумеется. Любой браузер будет ругаться на обращение по HTTP из HTTPS сессии.
На обращение по HTTP из HTTPS сессии на одном домене вроде бы. С других доменов все должно работать. Или я чего-то не учел?
Вообще корень проблемы в том как LS работает с изображениями. Хранить, конечно, нужно относительные пути — это бы сняло целую пачку проблем.
Самое веселое, что если заменить в БД полные пути на относительные — все очень даже отображается.
avatar
С любых доменов. если браузер грузит страницу по HTTPS, то все ресурсы которые грузятся вместе со страницей (картинки, CSS, JS — всё) тоже должны приходить по HTTPS, иначе будет WARNING от браузера.
avatar
Самое веселое, что если заменить в БД полные пути на относительные — все очень даже отображается.
Само собой. :) Ибо браузер замечательно резолвит относительные пути доменом. Почему я и не понимаю с какой целью вообще абсолютные пути в базу сохраняются. Смысл какой-то в этом был наверняка, но какой я не понял :)
avatar
Хранить, конечно, нужно относительные пути — это бы сняло целую пачку проблем.
Я решил это так
avatar
Как это решить-то понятно. Но я не люблю что-то ломать пока чётко не пойму, почему это было сделано.
avatar
Это не решит всех проблем. Плюс испортит работу функций «GetServerPath».
avatar
А так?
avatar
Как разовое решение при смене домена — очень даже неплохая идея (хотя я бы лично просто SQL-дамп отредактировал). Но к обсуждаемому вопросу штука мало применимая.
avatar
Подумайте ещё вот о чём. SSL-eм при правильном подходе будет заниматься NGINX. Т.е. back-end, будет всегда получать уже декодированный запрос и по HTTP Без всяких «S». И тогда ваш плагин, насколько я понял, работать не сможет :)
avatar
Не соглашусь, все зависит от того, что будет передано от NGINX к Apache в $_SERVER.
Хотя, этот вопрос надо проверять на реальных сайтах, но негде. А на локалке у меня только Apache.
avatar
Ну так я вам и говорю — от NGINX к апачу придет HTTP. Apache не увидит что там вообще был HTTPS, потому что кодирование/декодирование SSL это работа nginx и апач вообще не в теме. Обычно это решается путем ввода специального хедера в заголовок запроса. Техника аналогичная X-Forwarded-For для IP адресов. Т.е. по уму вам нужно проверять ещё и специфический заголовок.
avatar
Да, сейчас определение режима происходит по 3 методам:
1) $_SERVER['HTTP_SCHEME'] == 'https'
2) $_SERVER['HTTPS'] != 'off'
3) $_SERVER['SERVER_PORT'] == 443

Без Apache достаточно будет добавить в конфигурации NGINX что-то подобное и должно работать:
server {
	listen 443;
	server_name site.ru;
 
	ssl on;
	fastcgi_param HTTPS on; # Enable 
}


А вот с Apache другого пути похоже нет кроме
Обычно это решается путем ввода специального хедера в заголовок запроса. Техника аналогичная X-Forwarded-For для IP адресов.
avatar
Ну так о чём и речь. Т.е. всё что вам нужно сделать — ввести поддержку определенного заголовка (назвать его как-то, например, X-Secure-Connection) и документировать что нужно сделать администратору в конфигурации nginx и в каком случае. С примерами. :)
avatar
Вроде как есть:
proxy_set_header   X-Forwarded-Proto $scheme;
avatar
Ну или так :)
avatar
Ага, тоже наткнулся на упоминание $_SERVER['HTTP_X_FORWARDED_PROTO'].
avatar
Продолжаем :)

Проверка на порт 443 — это совсем НЕ ВЕРНО в случае X-Forwarded-Proto :)

На самом деле вообще не верно в общем случае.

Зачем?
avatar
Для голого Apache конечно. :)
avatar
Эта проблема, к стати, не только для связки Nginx+Apache актуальна. Всё глубже. Та же проблема есть когда у вас многосерверные конфигурации, т.е. вы балансируется нагрузку между несколькими серверами.
avatar
Изображения вообще не отображаются если залить аватарку через https и зайти через http, видео не показывает если не прописать путь https, обычно люди пишут через http
ошибка с js яндекс вызывает https но можно залить фаил на комп и проблемы не будет
ошибка шрифтов гугл хром, тоже надо залить себе на сайт и подключить через конфиг
ошибка фаерфокс, не изучена, до сих пор понять не могу
Есть 1 плюс если сайт был запушен, хоть 1 раз через https то http полностью работает
можете это проверить и поменять в конфиге http на https. При выключение браузера все сбрасывается и нужно снова входить в https, для отображение http
надеюсь помог улучшить бетку
  • lol
  • 0
avatar
У меня на локальном сервере (Debian) большинства из этих проблем не наблюдалось. Так что тут либо настройки сервера, либо настройки браузера.
Но я работаю над этим вопросом.
avatar
я забыл написать, я же проверяю мобильный шаблон, эти проблемы в мобильном шаблоне)
avatar
Добавлено исправление ссылок на JS и CSS файлы (в том числе внешние). «Яндекс.Поделиться» теперь подгружается нормально.

Но в шаблоне Synio необходимо немного подкорректировать не совсем корректную загрузку CSS.
avatar
не совсем корректную загрузку CSS
можно поподробнее, что именно некорректно загружается?
avatar
См. выше, баг 2.
avatar
Надо аватарки сделать, они не загружаются, если были загружёны через https:
avatar
Аватарки, фотографии и изображения из топиков.
avatar
везде где должна быть аватарка, нарисована поломанная фотография, типа файла нету.
avatar
1) Добавлено исправление ссылок на аватары и фотографии пользователей.
2) Добавлено исправление ссылок на изображения в фотосете.

Остается только ссылки на изображения в тексте топиков. Самое простое решение — парсинг текста топика и замена ссылок в тексте — мне не нравится, поскольку создаст дополнительную нагрузку при формировании страниц. Но альтернативы пока не вижу.
avatar
у меня аватарки пользователя все равно не показывает, видимо если они были залиты на сайте с https то вся структура падает.
avatar
Если залить аватар по HTTPS протоколу, то и при входе по HTTP она будет отображаться с «https://». Тут проблема в сертификатах вашего сайта и настройках браузера.
avatar
да это понятно, просто если сертификата нету.
может сделать, чтобы картинки загружались только через http даже если загрузил с https или так не как.
avatar
Сделать можно, но это не лучшее решение, поскольку при правильной настройке https-сервера, при работе по http-протоколу изображения по https-протоколу должны отображаться без проблем.
avatar
Остается только ссылки на изображения в тексте топиков. Самое простое решение — парсинг текста топика и замена ссылок в тексте — мне не нравится, поскольку создаст дополнительную нагрузку при формировании страниц. Но альтернативы пока не вижу.
Нормальное решение. И простое. Подрубить в плагин какой-нить HTML-парсер, (Simple HTML DOM, например) искать картинки и менять. В грамотном месте только. Я бы подменял тексты где-нить до того как они передаются в Smarty. Еще лучше — кэшировать данные уже после замены — но это уже намного сложнее будет сделать.

Это не настолько ресурсоемкая операция — замена текста в памяти. Работа с БД(которой до черта при отображении топика) намного хуже, например. С умом если сделать разницы в производительности и не заметит никто.

И линки в комментариях тоже.
avatar
И ещё. Если уж делать замену в линках картинок, то стоит пойти ещё чуть дальше — дать возможность менять домен. Чтобы можно было отконфигурировать а плагине домен который у картинок будет подменяться. И так же, конфиг параметром — менять домен только в HTTP или в HTTPS тоже. Это, за одно, и проблему с подключением CDN решит — и вот тогда это будет очень интересный плагин.
avatar
Чтобы можно было отконфигурировать а плагине домен который у картинок будет подменяться.
Так дубляж моего же «Домена для статики» будет.
avatar
В некоторой степени. но не одно и то же. дело в том, например, что многие CDN (Amazon CloudFront, как пример) не поддерживают HTTPS. Это значит что домен для CDN нужно подменять только если запрос не HTTPS. Т.е. вот вам и необходимость думать HTTPS или нет при этом.

Ну и потом, если всё равно линки надо менять — то уж всё сразу :)
avatar
Это не настолько ресурсоемкая операция — замена текста в памяти.
Ну, лучше ничего все равно не придумалось.
С умом если сделать разницы в производительности и не заметит никто.
Думаю, достаточно будет перекрыть функцию чтения из БД. Тогда и кеширование родное будет работать.
avatar
Там, боюсь, много методов придётся перекрывать.
avatar
А, и родное кеширование будет работать «но не совсем». Ключ для кеша же расширяется новым параметром — HTTPS или нет.
avatar
Кстати, работа с кешированием пока вообще не анализировалась. Спасибо за подсказку.
avatar
Может пригодится:
// all absolute path with main domain to relative path
$sRelativePath = preg_replace('~(http[s]?:\/\/.*?\/)~i', '/', Config::Get('path.root.web'));
$sResult = preg_replace('~((src|href)=")(' . Config::Get('path.root.web') . ')~musi', '$1' . $sRelativePath, $sText);

Вставляется в метод Parser модуля Text перед return.
Что делает: после прохода всех стандартных парсеров/обработчиков на исходным текстом находит теги с атриббутами href and src и, если домен совпадает с path.root.web, вырезает его.
Вырезается только домен 2-го уровня. Например: site.ru/ заменится на /, site.ru/livestreet заменится на /livestreet.
Результат: в БД пишутся тэги с относительныи путем.
avatar
Более правильный вариант:
$sWebPath = preg_replace('~http[s]?:\/\/~i', '',Config::Get('path.root.web'));
$sRelativePath = preg_replace('~^.*?(\/.*)~i', '$1', $sWebPath);
$sResult = preg_replace('~((src|href)=")http[s]?:\/\/' . $sWebPath . '~musi', '$1' . $sRelativePath, $sResult);

Например: основной домен
http://site.ru/

Исходный текст:
<img src="http://site.ru/..">
<a href="http://site.ru/">http</a>
<a href="https://site.ru/">https</a>
<a href="http://test1.ru/">ссылка на сторонний сайт</a>

Cоответственно в БД попадет:
<img src="/..">
<a href="/">http</a>
<a href="/">https</a>
<a href="http://test1.ru/">ссылка на сторонний сайт</a>
avatar
Исходный текст:
<a href="http://site.ru/">http</a>
<a href="https://site.ru/">https</a>

Cоответственно в БД попадет:
<a href="/">http</a>
<a href="/">https</a>
А вот имеет ли смысл подобная замена? Это не позволит разместить ссылку на HTTPS-версию на сайте, например (наоборот тоже).

Я считаю, что в рамках данного плагина правильнее исправлять только:
1) ссылки, которые генерируются на лету (на базе path.root.web) — сделано;
2) фиксированные ссылки на картинки (для фотосета) — сделано;
3) фиксированные ссылки на аватары и фотографии пользователей — сделано;
4) ссылки изображения в тексте топиков и комментариев.
А вот ссылки в тексте должны оставаться неизменными.
avatar
Всего-то убрать конструкцию [s]? в последней регулярке.
И идейно правильно разруливать доступ к ресурсам через http или https на уровне сервера/реверс-прокси, а не на php.
avatar
IMHO — я бы вообще не парился над тем что и как попадет в базу — туда по-разному попасть может. Вплоть до прямой модификации базы админом :) Корректировать линки на ресурсы при отображении данных — вот и всё.
avatar
В чем смысле это делать после? С тем же успехом модуль Text мог бы писать контент в базу без обработки, а после запроса в БД его обрабатывать. Но так почему-то никто не делает.
avatar
Смысл хотя бы в том, что вы не знаете и не можете знать чего и как вам в базу напихали другие плагины, о которых вы, как разработчик этого плагина, не знаете и не можете знать какие в конкретной установке LS работают вообще.
avatar
Каким образом связаны плагины с абсолютными/относительными путями топиков/комментариев?
avatar
Плагины могут помещать в тексты заметок и комментариев линки. любые. по любым причинам. и вы не можете это контролировать ибо это не ваш код и не код движка. и не факт что плагин реализован идейно правильно.
avatar
Раз кто-то игнорирует стандартые методы (с тем же успехом можно сразу отключить jevix), тогда — да, ваш вариант подходит. Менять адреса перед рендером страницы.
avatar
jevix он нужен для контроля чего там пихает в базу конечный пользователь. Он не нужен если по каким то причинам ваш сайт хочет какой-то линк в заметку добавить. (пример может и не лучший, но валидный). Т.е. игнорирование jevix может быть вполне сознательной и оправданной идеей в каких-то случаях. Из соображений производительности, например.
avatar
Абсолютные пути в базе на свой домен, это всегда геморрой при миграциях на другие домены.
avatar
Например, я обожаю безопасность и предпочитаю https. Я не хотел бы, переходя по ссылкам топика пользователя, который использовал http, в пределах основного домена, оказаться на http.
Если в базе относителые пути — это решает эту проблему.
avatar
Например, я обожаю безопасность и предпочитаю https.
Это вопрос тонкий. Засада заключается в том, что процесс SSL шифрования/дешифрования, как и любая криптография является очень затратным по CPU. Т.е. его желательно избегать, за исключением тех мест где он действительно нужен, ибо вы просто тратите ресурсы «на ветер».

А где оно надо? О! Очень клёвый вопрос в контексте LS. Ибо очень мало где. Какой смысл шифровать, например, публично всем доступную заметку? — а никакого смысла.

Фактически во всем LS есть буквально несколько мест где HTTPS действительно нужен — логин, регестрация, редактирование личных данных в профайле… и всё.

Во всех остальных случаях пользователя даже стоит заворачивать с HTTPS на HTTP путём HTTP 301. Чтобы даже не пытался шифроваться там где это не надо. Но сделать это очень не просто, конечно.
avatar
Вот как раз при миграциях на другие домены — это очень маленький геморрой. SQL-скрипт в 5 строк. Могу дать. :) Но это, конечно же, не особо удобно. Никто не спорит. Просто именно миграция — наименьшая из проблем.
avatar
Ошибка: Файл плагина не найден

avatar
Папку плагина необходимо переименовать из «livestreet_httpsdetect-master» в «httpsdetect».
avatar
Добавлена обработка ссылок на изображения:
— в тексте топиков;
— в тексте комментариев;
— в описании блога;
— в сообщениях;
— в записях на стене;
— в информации пользователей «О себе».
avatar
Проверил все работает
avatar
хотя не не все, изображения не показывает в сайт/blogs/
P.S мобильный шаблон
avatar
Какие именно изображения и где не показывает?
avatar
Изображения для блога, их не показывают если были залиты через https:
avatar
Понятно, аватар для блога.
avatar
Добавлено исправление ссылок на аватары блогов.
avatar
Все работает, кажись)
avatar
Надо еще на ошибки проверить и можно будет выпускать как полноценный плагин.
avatar
Вопрос с кешированием пока не рассмотрен.
avatar
попробуй ort спросить мож он знает как сделать.
avatar
Исправлено кешированние JS и CSS файлов — для HTTPS генерируются отдельные файлы.

Пару дней на тестирование всем желающим и добавлю в каталог.
avatar
Проверил, все вроде работает.
Кстати Wasja может кешированние JS и CSS файлов сохраняеть, так

\www\templates\cache\названия шаблона\

просто это по технологии движка лучше будет.
Если человек сделает 2 шаблона, все пойдет в папку https.
Например плагин мобильная версия и обычный шаблон, взаимодействие пойдет в 1 папку https
avatar
Если будет 2 шаблона, то будет так:
\www\templates\cache\названия шаблона 1\
\www\templates\cache\названия шаблона 2\
\www\templates\cache\https\названия шаблона 1\
\www\templates\cache\https\названия шаблона 2\

Просто это самый простой и наименее влияющий на код вариант.
avatar
А почему нельзя сделать \www\templates\cache\названия шаблона\ без https?
По идеи кешированние создает рандомное названия файлов. Разве есть совпадение что два файла будут с одинаковым названием?
avatar
Можно. На стандартных шаблонах они будут иметь разные названия.
Но, вообще возможен вариант, когда будут подключатся только CSS или JS файлы с абсолютными путями. В этом случае имена файлов для HTTP и HTTPS совпадут, а содержимое (при наличии ссылок на изображения) будет различаться.

В принципе могу сделать в качестве опции.
avatar
Ну попробуйте поэкспериментируйте.
по идеи должно все работать и без лишних папок https
avatar
— Добавлен параметр $config['separate_path'] — Использовать отдельный путь для хранения JS и CSS файлов HTTPS протокола. По умолчанию отключено (false).
— Добавлена обработка изображений в тексте статических страниц (плагин «Static Page»).
avatar
Добавлена обработка изображений в тексте статических страниц (плагин «Static Page»).
А что это за плагин? («Static Page»)
avatar
Стандартный плагин из поставки LS. :)
Для создания статических страниц.
avatar
А все нашел кажись, только не понял как это работает.
avatar
Нашел интересную фичу, наверно вам будет интересно.
Если использовать чат disqus.com/ переходя с http на https у вас будут 2 разных чата от disqus, я предполагаю, что с чатом вк и фейсбук будет тоже самое, хотя сам не проверял.
И думаю исправить такое нельзя не как, суть в том что скрипт берет url сайта, если же протокол http меняется на https, это значит другой URL
avatar
Вроде лечится — help.disqus.com/customer/portal/articles/542119
Проверить негде.
avatar
да я у себя оставил 2 чата на странице, это будет фишка такая)
avatar
А видео ссылке обрабатывает?
У меня не хочет, не через кнопку, ни в iframe.
avatar
Не обрабатывает.
avatar
Добавлен параметр $config['correct_video_src'] — Обрабатывать ссылки на видео в тексте топиков и комментариев.
Пока доступно только на GitHub.
avatar
Спасибо, пошел обновляться.
avatar
— Добавлена коррекция параметра конфигурации 'path.static.root'.
— Добавлена поддержка плагина «Domain for static».

Версия 1.0.1 отправлена на модерацию.
avatar
2. При использовании шаблона «Synio» идет загрузка Google-шрифтов по HTTP протоколу. Решение:
— в файле "/templates/skin/synio/header.tpl" удалить строку
<link href='http://fonts.googleapis.com/css?family=PT+Sans:400,700&subset=latin,cyrillic' rel='stylesheet'

ну это бредовая идея, удалять строку, если ее можно просто привести в https
https://fonts.googleapis.com/css?family=PT+Sans:400,700&subset=latin,cyrillic

это вот http умею грузить файлы с https а вот https увы не может этого делать
avatar
Спасибо большое за качественный плагин. Приятно видеть такие разработки — поставил и сразу все работает. Очень приятно. Еще раз спасибо.
avatar
сделал сайт через https, перестали работать сообщения через Ваш плагин через https, подскажите пожалуйста как решить
avatar
простите ошибся окном))) сообщение направлено разработчику «Реального плагина». Кстати может кто сталкивался?
avatar
Был вопрос — нашел ответ в вашем плагине.
Но проблема как его активировать? Если я немогу залогинеться из-за http
avatar
Достаточно вручную дописать название плагина (httpsdetect) отдельной строкой в файле "\plugins\plugins.dat".
avatar
Да разобрался — благодарю! Не было просто изначально файла (plugins.dat) чуть запутал этот момент =)

Скажите (я знаю что оно не поддерживаеться больше aceAdminPanel v.2.0.392)
Но как пофиксить ошибку с вашим плагином? Чтобы не ругался
Warning: Class 'PluginHttpsdetect_ModuleUser_EntityUser' not found in /var/www/gde/plugins/aceadminpanel/include/ACE.php on line 52
avatar
Боюсь, что это не ошибка с моим плагином. Это несовместимость плагинов, вызванная глубокой интеграцией aceAdminPanel в CMS. И, к сожалению, я не имею ни возможностей, ни желания, искать причины данной несовместимости.
avatar
Понял! Благодарю за ответ! Скорей всего свою придеться тогда писать.
avatar
Еще хотел уточнить имеет ли плагин совместимость с Nice URL или ЧПУ
То ошибки и в одном плагине и в другом, хотелось просто ясности, в моих руках проблема либо правда нету совместимости.
avatar
Да, данный плагин и плагин ЧПУ абсолютно не влияют друг на друга.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.