Иконка ресурса

Использование HTTPS (SSL) соединения с помощью .htaccess и mod_rewrite для XenForo

mishazajceff, дело в том, что https-протокол будет работать или на nginx или на apache. Вы не сможете проксировать с nginx на апач 443 порт, потому что порт один и тот же. Лично я не знаю как это может работать вообще.
Если при nginx на frontend проксирование возможно, например, с порта apache 8080 на порт 80 nginx, то как это сделать для 443 порта, я не знаю. Поэтому протокол http всегда будет работать в связке apache+nginx, а https либо на nginx либо на apache. Тут выбирает каждый, что ему удобно.
 
Последнее редактирование:
artloskutov, Большое спасибо за столь развернутый ответ, но для меня это, к сожалению, большой набор непонятных слов :(
Я надеялся, что ситуацию можно исправить несколькими кликами мыши, но, похоже, это не так...
 
Последнее редактирование:
По-хорошему, после перехода на https, надо включить проскирование изображений. Тогда вы не будете сталкиваться с ошибками, что страница содержит незащищенное содержимое.
 
  • Мне нравится
Реакции: Hope
Подниму тему.
Разве сейчас не достаточно просто в library/config.php добавить
PHP:
$_SERVER['HTTPS'] = 'on';

mishazajceff, дело в том, что https-протокол будет работать или на nginx или на apache. Вы не сможете проксировать с nginx на апач 443 порт, потому что порт один и тот же. Лично я не знаю как это может работать вообще.
Не совсем так. Можно проксировать https на https, например nginx проксирует x.x.x.x:443 на y.y.y.y:443, а там уже https подтягивает апач. Но, это используется если nginx и apache расположены на разных машинах и необходимо защитить соединение между ними. Пример: подключение cloudflare.

В классическом варианте, когда все крутится в рамках одного vds, нет смысла держать и https на апаче, это только зря сожрет ресурсы, которые как правило ограничены. Так что обычно nginx смотрит наружу и слушает на 443-м порту, на него же и лепим сертификат; в свою очередь он проксирует на локальный апач по обычному http.

Кстати, упомянутый cloudflare с недавних времен поддерживает https для бесплатных (free) аккаунтов, в том числе по схеме https -> cloudflare -> http нашего сервера, т.е. при желании каждый может обеспечить себе https без материальных вложений.
 
Последнее редактирование:
Подниму тему.
Разве сейчас не достаточно просто в library/config.php добавить
Этих тем на всем форуме за последнюю неделю штуки три подняли и везде этот идиотский способ с добавлением суперглобальной переменной. Это костыль! Нормально настраивайте свой сервер, чтобы с http-версии на https был редирект 301 и ничего дополнительно, тем более настолько костыльного, добавлять не придется. И тем более не надо это советовать.
 
Аргументируйте, в чем заключается костыль. $_SERVER['HTTPS'] - просто переменная, все остальное в коде движка:

PHP:
public function getAbsoluteUri() {

        // Checking if the request was made through HTTPS. The last in line is for IIS
        $protocol = isset($this->_SERVER['HTTPS']) && ($this->_SERVER['HTTPS']) && ($this->_SERVER['HTTPS']!='off');
        return ($protocol?'https':'http') . '://'  . $this->getHeader('Host') . $this->getUri();

    }

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

Останется еще один момент с ссылками в шаблонах, но он лечится с замены http://блабала на //блабла
Т.е. не указываем протокол, браузер сам подхватит нужный.
 
Последнее редактирование:
Smalesh, $_SERVER (как и $_GET, $_POST) это суперглобальная переменная и использование их в коде в том виде, который предлагаете вы, а именно переопределение - конечно в php не запрещено, но в данном конкретном случае - костыль. Как вы выше сами показали - в движке форума предусмотрены все необходимые проверки, а какие-то проблемы могут быть только в случае неполной настройки сервера, когда ресурс одновременно доступен и с SSL и без него. Сделайте нормальный, человеческий 301 редирект с http-версии на https-версию - и вся ваша ссылочная масса перестроится столь же нормально. Но не переопределяйте суперглобальную переменную - вы этим не избавляетесь от истинной причины проблемы, вы только маскируете ее.
 
который предлагаете вы
Нет, не я ;) . Это код взят из кода форума xenforo 1.4.4 и он отвечает за http/https.

Но не переопределяйте суперглобальную переменную - вы этим не избавляетесь от истинной причины проблемы, вы только маскируете ее.
Поясню. Что перевести vbulletin на https, достаточно просто указать ulr форума в виде . Это переменная bburl, от которой потом строятся все остальные ссылки, как-то ссылки на css, js, навигация и так далее. Если же в xenforo указать урл форума с протоколом https, то xenforo все равно при определенных условиях упрямо будет продолжать генерировать ссылки в http (см код выше). Это приведет к тому, что при обращению по https браузер может не загружать (как небезопасные элементы) скрипты, стили и так далее.

Теперь нарисую такую картину, проксирование https -> cloudflare -> http (так называемый режим ). Это рядовая ситуация для всех желающих обзавестись https, у которых по техническим причинам нет возможности поднять https -> cloudflare -> https (например, обычный виртуальный хостинг, где за выделенный ip нужно платить, а SNI не поддерживают). Или VDS-ка слабенькая, и ресурсов впритык. В этом случае SERVER['HTTPS'] или будет отсутствовать (nginx) или будет в off (apache), следовательно из-за этого кода выше, движок сам перейдет на http - уж так он написан, выдаст http -> браузер в https не загрузит css, js, прочее и тут уже редирект не поможет, т.к. браузер может просто не отравлять запрос на http (зависит от его настроек)

Таким образом, то что я в булке делаю через определение bburl, в xenforo я вынужден либо переопределять SERVER['HTTPS'] или влазить в код движка. И это более универсальное решение, чем редирект.

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

PSS: по хорошему указанный код служит для того, что бы автоматически переходить на https, если к нему обращаются по этому протоколу. Например, еще один вариант применения - в случае нехватки ресурсов, использовать https только для авторизации, когда идет передача чувствительных данных, все остальное время работая на менее ресурсоемком http.
 
Последнее редактирование:
Smalesh, приведенные примеры сами являются хаками. Там где нужен SSL он будет и будет не в виде обрезка от cloudflare, а обычным сертификатом, в крайнем случае тем от того же startssl.
И хочу напомнить, что насильственное включение перезаписи ссылок на https не блокирует доступ к форуму по http, так что в любом случае должен быть 301 редирект, если уже используется шифрование.
 
Там где нужен SSL он будет и будет не в виде обрезка от cloudflare, а обычным сертификатом, в крайнем случае тем от того же startssl.
Другой случай, банальная связка проксирующий ssl на nginx + apache, популярная до ужаса - и очень много где неправильное определение $_server 'https' (без передачи HTTPS $https на бекенд) -> описанная выше проблема. С удовольствием посмотрю на ваше решение этой задачи в этом случае. Хотя оно есть ;)

И хочу напомнить, что насильственное включение перезаписи ссылок на https не блокирует доступ к форуму по http, так что в любом случае должен быть 301 редирект, если уже используется шифрование.
Это зависит от поставленной задачи - ssl-only или оставить возможность классического http. Еще полезно заменить на httpsнашфорум простым sql запросом в самой базе.
 
неправильное определение $_server 'https'
Вот именно, что определять его должен веб-сервер, а не сам php, которые может не знать по какому протоколу идет запрос. Особенно эта ситуация будет важна, если я хочу не весь сайт по ssl, а только к примеру формы логина, регистрации и изменения персональных данных.
Это зависит от поставленной задачи - ssl-only или оставить возможность классического http
Основная цель перехода на шифрование - защитить передаваемые данные, в первую очередь конфиденциальные. Оставляю возможность ходить по http мы просто нивелируем все наши старания по защите.

Я все же останусь в споре на своем мнении, если у вас экзотическая архитектура подключения, то тут без хаков понятное дело не обойтись. Вполне вероятно, что есть ситуации в которых ваше решение будет единственным, но оно никогда не будет верным.
 
Вот именно, что определять его должен веб-сервер, а не сам php
А это и так переменная окружения web-сервера, php ее только читает и определяет у себя. Но сам веб-сервер (бекенд) может работать в http, а сертификаты будут висеть на фронтенде, переменной не будет или она будет fasle (ну не передается по определенным причинам), и начинается карусель с бесконечными редиректами. Как-то так.
 
Smalesh, я повторяю в третий раз, что переопределение глобальных переменных - большая ошибка, ну вернее костыль. Переменная $_SERVER самим php-сервером определяется, а то что вы ее задали принудительно - опять же лишь маскировка проблемы. Сервер у вас значит работает по сути с http, а вы ему принудительно заявляете что это https. Проблема с flexible ssl от cf надумана, у себя использую cf и там опять же все решается принудительным редиректом всего через 301 редирект на защищенную версию.
Если же в xenforo указать урл форума с протоколом https, то xenforo все равно при определенных условиях упрямо будет продолжать генерировать ссылки в http (см код выше). Это приведет к тому, что при обращению по https браузер может не загружать (как небезопасные элементы) скрипты, стили и так далее.
Да, все так - это основная "проблема" с которой сталкиваются, прикрутив cf (их новый univelsal ssl бесплатный) на форум с XenForo. И проблема в том, что работа с сервером настроена по двум протоколам, что в принципе некорректно. Если сервер будет работать принудительно по https, что правильно, такой проблемы в принципе не будет, потому что переменная $_SERVER['HTTPS'] и так будет true.
Я все же останусь в споре на своем мнении, если у вас экзотическая архитектура подключения, то тут без хаков понятное дело не обойтись. Вполне вероятно, что есть ситуации в которых ваше решение будет единственным, но оно никогда не будет верным.
Полностью согласен.
 
что делать вроде настроил всё правильно но форум отображается не корректно
 

Вложения

  • 5ovKCJjKLUk.jpg
    5ovKCJjKLUk.jpg
    144.6 KB · Просмотры: 82
из-за чего может быть такой значёк
Включить проксирование изображений и ссылок и проверить скин на предмет ссылок , заменить на //, т.е. убрать жесткое указание протокола. Только внимательно, понимая что и где делаешь.
 
я нажал прочитал ,
Нажмите на него и прочитайте. :-)
Включить проксирование изображений и ссылок и проверить скин на предмет ссылок , заменить на //, т.е. убрать жесткое указание протокола. Только внимательно, понимая что и где делаешь.
2 пункт не совсем понял ,убрать жёсткое указание протокола это где
А ещё как сделать редирект или как настроить у меня когда на сайт заходишь сразу http открывается вместо HTTPS пробовал в хосте редирект сделать так он вообще перестал сайт открывать
 
Современный облачный хостинг провайдер | Aéza
Назад
Сверху Снизу