Вход • Регистрация

Настройка SSL-сертефиката

  •
  • 27 апреля 2015 г.
  • Говорят где-то тема такая была, поиск ничего не дал, может кто поделиться ссылочкой на топик
    • 27 апреля 2015 г.
    • по-моему надо искать по теме настройки яндекс денег, так как они требуют такую штуку
  •
  • 28 апреля 2015 г. , редакция: 28 апреля 2015 г.
  • Вроде заработало, вот только теперь нужно чтобы все пути до файлов и ссылки были с https://, чтобы когда открыть код страницы, не одного http:// - не было. Кто подскажет что и где нужно править?
    •
    • 30 апреля 2015 г. , редакция: 23 января 2017 г.
    • Да ничего делать не надо. Оно автоматически должно сработать.
      У нас в index.php же стоит
      Код
      define('BASE_PATH', "http".(isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] != 'off' ? "s" : '')."://".getenv("HTTP_HOST")."/".(REVATIVE_PATH ? REVATIVE_PATH.'/' : ''));

      оно определяет переменную BASE_PATH, от которой вся CMS формирует все ссылки. Она по умолчанию http, но, как видите, если инициализировалось https, она определяется тоже как https.
      Это касается всяких ссылок в модулях, меню, новости, товары и пр.
      Но если где-то в шаблоне Вы сами http поставили, сайт перескакивает на http и тогда всё.

      Нужно только прописать редирект в htaccess с http на https и сбросить кеш
  •
  • 30 июля 2015 г.
  • Насколько я понял, проблема не работы автоопределения http/https возникает при использовании на сервер nginx, и с ещё большей вероятностью это проявляется в том случае, если за nginx находится Apache MPM-ITK. Потому что для корректной работы с данным кодом требуется fastcgi_param HTTPS on, т.е. мало того что настройка должна присутствовать в nginx, но и сам апач должен быть собран в Apache PHP-FPM FastCGI. И как бы это всё очень не однозначно.
    Поправьте если я ошибаюсь.
  •
  • 23 октября 2015 г. , редакция: 23 октября 2015 г.
  • Ну что ребята - Будете пробовать HTTPS?
    Проект Let’s Encrypt был создан новый центр сертификации, раздающий цифровые сертификаты для шифрования трафика по HTTPS всем и бесплатно.
    Пока сервис заработал в формате закрытого бета-теста, но убедиться в том, что все по-настоящему, можно зайдя на сайт helloworld.letsencrypt.org, созданный специально в демонстрационных целях.
    Полноценный запуск «для всех» запланирован на 16 ноября 2015 года.
  •
  • 20 декабря 2015 г.
  • Как обстоят дела с простым и универсальным использованием https?
    И Вы и мы позиционируем Diafan CMS как изначально оптимизированную для поисковиков, говорим клиентам о том, что сайты, сделанные на Diafan будут максимально соответствовать рекомендациям поисковиков. Но как можно на это опираться, если использование https невозможно запустить ни «по-умолчанию», ни какими-либо простыми настройками. Для этого приходится искать и править отвечающие за это файлы и ждать, когда же ещё что-то «отвалится». Да, Вы говорили о том, что при определённой конфигурации сервера всё работает само по себе, но судя по всему в эту конфигурацию нужно угадать, да и не является она оптимальной и поголовно используемой.
    •
    • 20 декабря 2015 г. , редакция: 20 декабря 2015 г.
    • Цитата
      Но как можно на это опираться, если использование https невозможно запустить ни «по-умолчанию», ни какими-либо простыми настройками.

      ОНЛАЙН СОФТ (ONMASTER), Вы точно понимаете, что такое https? Cms.diafan - это, грубо говоря, один большой скрипт, а http/https это протоколы передачи данных. Cms без разницы как передаются данные. А корректность работы протоколов зависит от настройки серверных служб. Что именно у Вас не работает?
      •
      • 20 декабря 2015 г.
      • Не понимает, очевидно. Я уже и молчу, не спорю, не доказываю ничего, устал.
        Хотя говорил без единицы тысячу раз: настройте сертификат на хостинге, чтобы сайт открывался как httpS://site.ru и всё. Как только всё будет сделано, и появится зеленая строка, DIAFAN.CMS всё остальное подхватит. Но сертификат ставится на сервере, на хостинге! А видимо, ожидается, что "запустить sll" должна цмс.
        • 20 декабря 2015 г. , редакция: 20 декабря 2015 г.
        • Учитывая такие вопросы, возможно они намекают на необходимость в дополнении к cms.diafan в виде, например, ispmanager, и имеющим бессрочную связку с сертификационным центром (конечно же намекают о бесплатном дополнении). В принципе, у Вас (разработчиков) уже всё к этому практически готово (облачный сервис уже есть, остается центр сертификации) ...
          Будущее развитие cms, тогда, например, можно будет посвятить тому, чтобы система сама заполняла товар и самостоятельно занималась парсингом
          •
          • 20 декабря 2015 г.
          • Не забудьте добавить искусственный интеллект, пусть сама с клиентами разбирается.
            •
            • 20 декабря 2015 г.
            • И бухучет ведет, отчетность сдаёт, и в случае чего, в налоговую сама ездит.
        •
        • 21 декабря 2015 г.
        • Хорошо, давайте, для того чтобы всё стало понятно, ;) мы возьмём какой-нибудь сайт, уже нормально работающий по протоколу http на Diafan CMS и запустим по https. Мы даже установим туда сертификат! :)
          И в этой ветке, с непосредственным участием разработчика, разберём что к чему, за одно разыграем лицензии на Diafan CMS в честь успешного запуска сайтов на Diafan по протоколу https без навыков программирования и досконального знания движка.
      •
      • 21 декабря 2015 г.
      • ВИТАЛИЙ (NVGPRO), Вы точно учили только теорию/читали википедию или всё же пробовали это использовать на разных сайта/CMS размещаемых на разных серверах?
        •
        • 21 декабря 2015 г. , редакция: 21 декабря 2015 г.
        • Онлайн Софт (Onmaster), даже не знаю с чего начать.
          Цитата
          Вы точно учили только теорию/читали википедию или всё же пробовали

          Не сочтите за наглость, но это тоже самое, что спросить золотую рыбку: "Вы плавать умеете или только желания исполняете?"
          Цитата
          Хорошо, давайте, для того чтобы всё стало понятно, ;) мы возьмём какой-нибудь сайт, уже нормально работающий по протоколу http на Diafan CMS и запустим по https. Мы даже установим туда сертификат! :)
          И в этой ветке, с непосредственным участием разработчика, разберём что к чему ...

          Скажите прямо о Вашем предложение (вознаграждение за работу) и если оно будет интересным Ваши проблемы будут решены.
          Цитата
          разместите по парочке сайтов на Diafan которые Вы сами сделали и запустил на https

          Тогда это будет не форум, а сео сборник ссылок на сайты с cms.diafan.
          Вам же Виталий (DIAFAN.CMS) привел пример:
          Цитата
          https://user.diafan.ru - достаточно?

          Но учитывая, что Вы все же настаиваете
          Цитата
          Виталий :), Ваши слова не могут быть убедительными или нет, Вы разработчик, у Вас другие задачи. Мы пробуем поднять свои глаза, но видимо до Ваших небес они не дотягиваются. У нас тоже найдется парочка "вымученых" вариантов, но мы никак не можем сдать их клиенту из-за того, что не уверены в стабильности работы.

          Пожалуйста, привожу пример (оставляю право за модератором данного форума удалить приведенную мной ссылку без предупреждения и объяснения причин, т.к. сам все понимаю): https://erland.ru/.
          А теперь, как говориться, начну с самого начала, Онлайн Софт (Onmaster)
          Цитата
          Что именно у Вас не работает?
  •
  • 21 декабря 2015 г.
  • Для всех же остальных, активно участвующих в дискуссии и строящих предположения:
    разместите по парочке сайтов на Diafan которые Вы сами сделали и запустил на https, а то как-то не убедительно звучат Ваши слова.
    •
    • 21 декабря 2015 г.
    • И мои неубедительно? Глаза поднимите выше, в адресную строку, https://user.diafan.ru - достаточно? Или Вы подозреваете, что он не на DIAFAN.CMS работает?
      • 21 декабря 2015 г.
      • Виталий :), Ваши слова не могут быть убедительными или нет, Вы разработчик, у Вас другие задачи. Мы пробуем поднять свои глаза, но видимо до Ваших небес они не дотягиваются. У нас тоже найдется парочка "вымученых" вариантов, но мы никак не можем сдать их клиенту из-за того, что не уверены в стабильности работы.

        Если вы не против чуть-чуть опустить свои глаза на бренную землю, то вот вам реальность:

        http://test.onsoft24.com/

        https://test.onsoft24.com/

        Так оно "выглядит из коробки". Возможно мы что-то упускаем и будем признательны Вам за указания на наши недочёты ;)
        •
        • 21 декабря 2015 г.
        • Конечно упускаете Самое очевидное и частое из ошибок - не обрабатываются некоторые ресурсы base path при внедрении дизайна. Чуть позже скажу конкретнее, а то сейчас с телефона, исходник не могу посмотреть.
          Кстати, в техподдержку хоть раз обращались с этим сайтом?
          •
          • 21 декабря 2015 г.
          • То есть <insert name="path"> не подходит для корректного указания путей?
            •
            • 21 декабря 2015 г.
            • Denis (Drachoon), я понимаю, что Вы ответ знаете, поэтому повторюсь для тех, кто не читает документацию
              Цитата
              То есть <insert name="path">

              Им и надо пользоваться, если самовольно не переопределена константа BASE_PATHE
          •
          • 21 декабря 2015 г.
          • Да, конечно писали и там рекомендовали сначала внести правки в одни файлы, затем в другие. После этого основа вроде как работала, но в будущем мы наткнулись ещё на моменты где обработка https не проходила нормально и браузер сообщал о незащищённом содержимом. К тому моменту мы уже перестали помнить все файлы, которые поправили и места, которые в них правили и поняли, что, наверное, это не верный путь.
        •
        • 21 декабря 2015 г. , редакция: 21 декабря 2015 г.
        • Цитата
          Так оно "выглядит из коробки". Возможно мы что-то упускаем и будем признательны Вам за указания на наши недочёты ;)

          У Вас в теле html кода присутствуют ссылки на ресурсы в виде http, а надо, чтоб были https.
          Цитата
          ВИТАЛИЙ (NVGPRO), Вы точно учили только теорию/читали википедию или всё же пробовали

          да это не в викепедии ...
          Если страница сайта передается в защищенном режиме, но при этом в теле страницы есть "незащищенные" (обычные http) ссылки на иные ресурсы, то браузер, который Вы используете, считает Вашу страницу "не совсем защищенной" (с содержанием опасного контента). Т.е. гость, который к Вам пришел на сайт по средствам защищенного обмена информацией должен быть уверен в том, что все, что подгружается в месте с этой страницей идет по шифрованному соединению.
          Т.е. делайте все ссылки по следующей формуле (пример):
          <?php echo BASE_PATH; ?>css/style.css
          Или альтернатива - шаблонный тег, который уже использует данную конструкцию
          •
          • 21 декабря 2015 г.
          • Это понятно но для вывода этих путей используются теги DiafanCMS <insert name="path"> получается что они не работают. Вместо ожидаемых https:// они возвращают http://, в документации по этому поводу ничего не написано. Вот и получается что на данный момент выход, убирать конструкции <insert name="path"> и писать в ручную https://
            •
            • 21 декабря 2015 г. , редакция: 21 декабря 2015 г.
            • Все работает. Есть только один момент, который на мой взгляд является ошибочным в cms.diafan, но он не оказывает ни какого влияния на процесс шифрования. Этот момент заключается в следующем:
              Когда работает model, то полученные массивы заносятся в кеш (с этим не спорим). Чтобы было более понятно, привожу пример:
              работает shop.model, формируется информация о товаре и заносится в кеш, но в месте с товаром в кеш заносится информация о картинках (их URL). При этом пути указываются абсолютные.
              Поэтому если страница в первый раз открыта как http, то и URL картинок запишется в кеш как http. Затем другой пользователь зайдет на туже страницу как https и получит в ответ страницу содержащую источник картинки как http - ВОТ И ОШИБКА.
              Решение простое: пишим в кеш не абсолютные, а относительные пути, тогда все ОК. Но тогда возникнет еще одна проблема. Например, письмо о заказе (содержащие картинки) будет отослано на email с относительными URL, т.е. они (картинки) в письме не отобразятся. Решение: в отправляемых письмах правим относительные пути на абсолютные. Далее возникает желание сохранить все как есть, т.е. в отдаваемой странице хочется, чтобы картинки были абсолютные. Решение: на выходе делаем подмену адресов.
              Это описана одна ситуация, но связанная с кешем, есть и другие, но принцип тот же.
              В общем звучит так, что надо кучу всего сделать. На самом деле пару строк откорректировать. Уверен это сможет сделать каждый, поэтому код не привожу.
              •
              • 21 декабря 2015 г.
              • Ну вот, тогда получается что есть какие-то причины по которым <insert name="path"> отказывается работать - неплохо было бы понять где их искать.
              •
              • 21 декабря 2015 г.
              • Да, это так и есть. Однако, здесь универсального решения нет. Ресурсы по абсолютным адресам грузятся быстрее, и проблем с ними нет, поэтому в кеш они записываются именно так.

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

                Речь о том, что во-первых, если настраивается сертификат для работы сайта по httpS,то зачем нужно оставлять http? Как видите, http://user.diafan.ru имеет редирект на https://user.diafan.ru и это правильно. Это по феншую.
                Во-вторых, тоже по феншую, режим разработчика нужно включать, а кеширование ВЫключать на моменты любых манипуляций с сайтом. Если настраивается сертификат - вырубайте нафиг кеширвание, пока всё не сделаете! Когда сделали, настроили, редиректы-шмедиректы, сайт готов к работе - последним движением перед запуском включаете кеширование и режим разработчика выключаете.
                Всё. С этого момента кеш нормально сформируется, и в нем не будет никаких ресурсов с http!
            •
            • 21 декабря 2015 г.
            • Да, там все ресурсы идут по https
              view-source:https://test.onsoft24.com/
              Судя по всему, она там вписаны напрямую в шаблон.
              Лучше show_css использовать, или да, show_path
              И кеш сбросьте и отключите! И редирект с http!
  •
  • 21 декабря 2015 г. , редакция: 21 декабря 2015 г.
  • Denis (Drachoon)
    Цитата
    Ну вот, тогда получается что есть какие-то причины по которым <insert name="path"> отказывается работать

    Вот именно поэтому я и сомневался, стоило ли мне писать здесь (так как тема называется "Настройка SSL-сертефиката") о своем мнении (которое относится к логике формирования кеша), так как из-за этого Вы посчитали, что что-то не работает. Я немного Выше писал
    Цитата
    Cms без разницы как передаются данные. А корректность работы протоколов зависит от настройки серверных служб.

    Поэтому вывод: Да ВСЕ работает (SSL не может конфликтовать с CMS), так как те данные которые формирует cms.diafan ни как не влияют на процесс шифрования.
    Цитата
    неплохо было бы понять где их искать

    Чуть выше я написал, что искать их надо в логике формирования кеша. Да в принципе там и искать-то не надо, несколько строк от корректировать.

    Если конечно это необходимо, данную инфу вместе с решением могу скинуть в ТП, но боюсь им и так все мозги вынесли,
    т.к. "чуть что не так", так сразу в ТП, нет чтоб подумать
  •
  • 21 декабря 2015 г.
  • Работает ВСЕ только работает не корректно. Никто не говорит, что что-то с чем-то конфликтует, уж тем более о шифровании. Речь о том, что CMS формирует http урлы вместо https и искать где нам нужно заменить одно на другое не совсем верный путь, т.к. это далеко не один фал нуждающийся в правках. Более того, внеся эти правки сайт перестаёт корректно работать по http и это тоже не правильно.

    Из переписки с тех.поддержкой по этому вопросу:

    DIAFAN.CMS: http:// прописано в файле adm/themes/adminauth.php. Замените в этом файле http:// на https://.

    Мы: Пару http:// заменили, но видимо это ещё не всё. Т.к. некоторые блоки вывдятся так:
    <insert name="show_head">
    <insert name="show_background">
    и в них присутствуют http://, хотя на самом сайт всё решается изменинем одной строки с
    define('BASE_PATH', "http".(isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] != 'off' ? "s" : '')."://".getenv("HTTP_HOST")."/".(REVATIVE_PATH ? REVATIVE_PATH.'/' : ''));

    на

    define('BASE_PATH', "https://".getenv("HTTP_HOST")."/".(REVATIVE_PATH ? REVATIVE_PATH.'/' : ''));

    и даже если залогиниться, то внутри админки всё тоже как то сумбурно.

    Мы не против в качестве эксперимента отредактировать файлы вручную, но точно нет более простого способа использовать https? :)

    DIAFAN.CMS: К сожалению, ничего более простого посоветовать Вам не можем.

    DIAFAN.CMS: Если код не срабатывает, значит не задана серверная переменная $_SERVER['HTTPS']. Предоставьте временный доступ к сайту по FTP для того, чтобы мы могли протестировать дополнительный способ проверки.

    Всё работает, серьёзно? :)
    •
    • 21 декабря 2015 г.
    • adm/themes/adminauth.php - это админской зоны файл, при чем тут публичная зона сайта? Там правда есть пару как бы внешних ссылок на http, на которые мы могли не обратить внимание и на которые может ругаться сертификат. Это решается заметкой в багтрек. Но речь же про сайт. Техподдержка спросила у Вас доступ по фтп, однако Вы его не дали и перестали вообще писать в этот тикет. Это было в июле. Если надо решать вопрос, его надо решать до конца.
  •
  • 21 декабря 2015 г.
  • Т.е. по Вашему "феншую" пути назад в http быть не должно?

    В приведённом примере редирект отключен для того чтобы можно было понять, как выглядеть "до" и "после".

    На приведённых мною примерах нет папки cache и файла index.html нет, не знаю хорошо это или нет, но как-то вот так. Видимо и кэш не используется?

    Ну и ответа на вопрос что же мы (не CMS и её файлы) делаем не так, я не увидел, ну или может опять что-то упустил из виду, столько полезной информации по теме вопроса.
    •
    • 21 декабря 2015 г.
    • Цитата

      Т.е. по Вашему "феншую" пути назад в http быть не должно?
      Нет, конечно. А зачем? Можете оставить, но с кешированием не будет работать, Виталий выше объяснил почему.

      Цитата
      Ну и ответа на вопрос что же мы (не CMS и её файлы) делаем не так, я не увидел

      Раза три вроде говорил. Проблема в Ваших шаблонах дизайна. Пути к ресурсам не обрабатываются path. Вслепую сложно сказать, без ftp к серверу, не видя код.
      Конечно, это работа. Надо садиться и обрабатывать ВСЁ path-ом в шаблоне дизайна. Цмс это сама не сделает.
      •
      • 21 декабря 2015 г. , редакция: 21 декабря 2015 г.
      • Цитата
        Цмс это сама не сделает

        Да может cms, как вариант - на выходе preg_replace'сом отработать в зависимости от текущего протокола соединения. Но я б на это не пошел, т.к. время прогрузки дорого. Лучше с кешом отработать. Только не создавать две копии кеша, т.к. память дорога. В общем я пошел по другому - всего-то пара строк и все ОК
    •
    • 21 декабря 2015 г. , редакция: 21 декабря 2015 г.
    • Онлайн Софт (Onmaster), ссылку, которую я привел выше, таких проблем нет (хоть http, хоть httpS), добавлю: при запросе с мобильных устройств cms перейдет на поддомен (при этом это одна и та же cms и база данных, т.е. не копия), админ как по http, так и по https (при этом принудительно протокол не требуется выставлять).
      К чему я это, Онлайн Софт (Onmaster), у Вас же статус многолетнего партнера, разработчика. Я не поверю, что вопрос 15 минут для вас катастрофа
  •
  • 21 декабря 2015 г.
  • Ещё раз повторюсь, мы можем "вымучать" это, но считаем, что это не правильный путь. Это не архиуникальная задача и это должно работать без "плясок с бубном" и "замены пары файликов". Мы не против правильной вёрстки и настройки, но против правки файлов CMS под такого рода типовые вопросы. Это должно либо работать из коробки, либо иметь настройку через админку/конфиг, как включение/выключение кэширования. Для того чтобы его включить Вы ведь не правите рабочие файлы CMS и не руководствуетесь "феншуями" настройки сервера, хотя там тоже есть разные варианты?

    И да, если всё дело только в path, то отчего же "сыплется" админка? Там мы используем "стандартный шаблон" :)
    •
    • 21 декабря 2015 г.
    • Цитата
      отчего же "сыплется" админка? Там мы используем "стандартный шаблон" :)
      Ну мы тоже не красны девицы вам, ошибок не делать. Могли что-то забыть-упустить, как, например, с http в adm/themes/adminauth.php. В багтрек письнули, мы исправили, и в будущем этих косяков не будет уже. Опять же, Виталий (NVGPRO) не жалуется, например, как и многие другие. У него всё ок, получается?
      •
      • 22 декабря 2015 г. , редакция: 22 декабря 2015 г.
      • Цитата
        Опять же, Виталий (NVGPRO) не жалуется

        Лично мое понимание: если платят за сопровождение, то это не подразумевает, что сопровождающий переспрашивает у ТП или ссылается на то, что это косяк cms. Сопровождающему платят за решения вопросов (у него же статус - разработчик). Приведу реальный пример: в банке выявлена не разрешенная активность (причина косяк на уровне протоколов). Банку без разницы, что это не косяк ПО.
  •
  • 21 декабря 2015 г.
  • Я не знаю, как и что у кого-либо получается. Судя по некоторым высказываниям и предложениям даже в этой ветке чувствуется заинтересованность в наличие некоторых проблем в CMS, видимо для кого-то это лишний повод заработать на «правке некоторых файлов».
    Нам же хочется, чтобы CMS была максимально удобной и требовала минимального кол-ва вмешательств для нормальной работы. Именно поэтому мы сообщаем о подобного рода вопросах, дабы решить их, а не корить в том, что есть эти недочёты.
    Я привёл пример того, как это видим мы и наверняка другие пользователи, которые пытаются следовать рекомендациям поисковиков запуская сайты на https. Если бы всё работало как нужно, подобная проблема не проявлялась бы. Мы же не стали бы писать о ней, не потратив для её изучения приличного кол-ва времени.
    В сухом остатке мы имеем ответ со смыслом «ну у других как-то работает вроде, поковыряйтесь там, и у вас должно». Да, у нас тоже это может работает. Только для этого приходится тратить время и отслеживать ситуацию, ведь CMS иногда обновляется и в ней что-то меняется. Возможно это не критично, если это твой единственный сайт, но, если ты хочешь запускать сайты более-менее регулярно, а зарабатывать на их нормальной работе, а не на мелких правках, которых могло бы и не быть, то это немного раздражает.
    •
    • 21 декабря 2015 г.
    • Извиняюсь за странный вопрос, но он важен. А Вы файлы cms обновляете или Ваша ситуация относится к какой-то определенной версии файлов cms?
      •
      • 21 декабря 2015 г.
      • Обновления это отдельная «нерабочая» тема , но здесь не об этом. Скорее речь о какой-то определённой версии 5.4
    •
    • 21 декабря 2015 г. , редакция: 21 декабря 2015 г.
    • Цитата
      Именно поэтому мы сообщаем о подобного рода вопросах, дабы решить их, а не корить в том, что есть эти недочёты.
      Куда? На форум? Отсюда дело не сдвинется. Дать ссылку на багтрек?
  • 21 декабря 2015 г.
  • С начало в тех.поддержку, но там "К сожалению, ничего более простого посоветовать Вам не можем.", потом на форум, но тут "И бухучет ведет, отчетность сдаёт, и в случае чего, в налоговую сама ездит.", давайте напишем в багтрекер и подождём когда это там окончательно похоронится.
    Считаете что проблемы нет, хорошо, читайте так дальше.
    •
    • 21 декабря 2015 г.
    • Цитата
      С начало в тех.поддержку, но там "К сожалению, ничего более простого посоветовать Вам не можем.",
      Чего Вы прицепились к словам и талдычите их без остановки? Что должна была техподдержка сказать-то??? Если в шаблоне вручную прописано "http", то единственный вариант это исправить - изменить вручную! Техподдержка так и сказала! Вы сами не поменяли, доступ к ftp не дали, сидите чего-то ждёте. Что произойти-то должно? Волшебство? Http само собой на https в шаблоне поменяется???
      •
      • 21 декабря 2015 г.
      • Я еще раз говорю, то, что в админке http прописано в шаблоне - опечатка/ошибка, и о ней надо писать в багтрек, чтобы её исправили в коробке.
        Если Вы получаете удовольствите от того, что строчите на форуме, общаетесь с коллегами, и результат неважен, то пожалуйста
      • 21 декабря 2015 г.
      • Ну если тех.подержка оценив ситуацию сама добавляет в багтрекер информацию об опечатке/ошибке, а разработчики её устраняют в течении хотя бы 5 месяцев это волшебство, то да, наверное, мы ждём именно волшебства.

        Что касается шаблона, бегло глянул, там следующее:

        <head>
        <insert name="show_head">
        <meta name="viewport" content="width=1170">
        <link href="<insert name="path">css/reset.css" rel="stylesheet" type="text/css">
        <link href="<insert name="path">css/style.css" rel="stylesheet" type="text/css">
        <link href="<insert name="path">css/animate.css" rel="stylesheet" type="text/css">

        На сайте (view-source:https://test.onsoft24.com/) выводится как:
        <meta name="viewport" content="width=1170">
        <link href="http://test.onsoft24.com/css/reset.css" rel="stylesheet" type="text/css">
        <link href="http://test.onsoft24.com/css/style.css" rel="stylesheet" type="text/css">
        <link href="http://test.onsoft24.com/css/animate.css" rel="stylesheet" type="text/css">
        <script type="text/rocketscript" data-rocketsrc="http://test.onsoft24.com/js/jquery.min.js" charset="UTF-8"><</script>

        да, в шаблоне есть ряд абсолютных ссылок с http, но это линки кнопок, не влияющих на визуальную составляющую сайта.
        •
        • 21 декабря 2015 г.
        • Цитата
          Ну если тех.подержка оценив ситуацию сама добавляет в багтрекер информацию об опечатке/ошибке, а разработчики её устраняют в течении хотя бы 5 месяцев это волшебство, то да, наверное, мы ждём именно волшебства.
          У техподдержки одна задача, поддерживать пользователей. Оценить ситуацию и пойти что-то перенести в багтрек техподдержка может, но это в круг её обязанностей не входит. Тем более, если пользователь не дал доступ к серверу, чтобы убедиться в ошибке.
          Если же баг попадает в багтрек, конечно, рассматривается он приоритетно в ближайшие дни после публикации, какие там месяцы...
          Цитата
          Что касается шаблона, бегло глянул, там следующее:
          Ну а у меня с <insert name="path"> проблем нет, она выводит корректные https. Что там есть у Вас еще, я не знаю, я все Ваши серверные файлы не видел. Надо отключать кеширование, включать режим разработчика, и трассировать, смотреть что там где сбивается на Вашем хостинге. Не хотите давать техподдержке доступ, ковыряйтесь сами, в чем проблема?
          •
          • 22 декабря 2015 г.
          • Доступ к ftp предоставил, но не для того чтобы настроить конкретный сайт, а для того, чтобы разобраться в чём именно заключается проблема.
        •
        • 22 декабря 2015 г. , редакция: 22 декабря 2015 г.
        • Я не смог у себя найти дистрибутив cms.diafan 5.4.8.4 (нашел только 5.4.9.9) Поэтому исхожу из последней версии.
          Шаблонный тег в дефолтной версии работает без сбоев. А так как в html коде у Вас присутствует только одна проблема (связанная с определением протокола ссылки http/https) и учитывая Ваши заверения
          Цитата

          Что касается шаблона, бегло глянул, там следующее:

          <head>
          <insert name="show_head">
          <meta name="viewport" content="width=1170">
          <link href="<insert name="path">css/reset.css" rel="stylesheet" type="text/css">
          <link href="<insert name="path">css/style.css" rel="stylesheet" type="text/css">
          <link href="<insert name="path">css/animate.css" rel="stylesheet" type="text/css">

          То делаю вывод, что ИМЕННО у ВАС не корректно работает шаблонный тег <insert name="path">. Данный шаблонный тег определяет путь к файлу исходя из констант ABSOLUTE_PATH, __FILE__, глобального массива переменных $GLOBALS. Учитывая изложенное считаю, что необходимо проверить именно в Ваших файлах корректность работы шаблонного тега.
  •
  • 22 декабря 2015 г.
  • Возможно вы говорите вот об этой ошибке
    Могу скинуть свое решение.
    •
    • 22 декабря 2015 г.
    • Вот, берите пример с Андрея. Пошел спокойно в багтрек и запостил замечание, без криков и угроз распятием.
    • 22 декабря 2015 г. , редакция: 22 декабря 2015 г.
    • такое решение?
      define('BASE_PATH', "http".(((isset($_SERVER['HTTPS']) && ! empty($_SERVER['HTTPS']) && $_SERVER['HTTPS'] != 'off')||(isset($_SERVER['HTTP_X_HTTPS']) && ! empty($_SERVER['HTTP_X_HTTPS']) && $_SERVER['HTTP_X_HTTPS'])) != '1' ? "s" : '')."://".getenv("HTTP_HOST")."/".(REVATIVE_PATH ? REVATIVE_PATH.'/' : ''));
      •
      • 22 декабря 2015 г. , редакция: 22 декабря 2015 г.
      • Выглядит похожим на правду, но еще подобные алгоритмы есть в админке.
        adm/includes/init.php
        в функции init
        Код
        define('BASE_PATH', "http".(isset($_SERVER['HTTP_X_HTTPS']) && $_SERVER['HTTP_X_HTTPS'] != '0' ? "s" : '')."://".getenv("HTTP_HOST")."/".( REVATIVE_PATH ? REVATIVE_PATH.'/' : '' ) );
  •
  • 22 декабря 2015 г.
  • Спасибо Андрею что предоставил доказательства недальновидности утверждавших что все работает и проблем нет ;)
    •
    • 22 декабря 2015 г. , редакция: 22 декабря 2015 г.
    • Это особенности настройки конкретно Вашего web сервера
      •
      • 23 декабря 2015 г. , редакция: 23 декабря 2015 г.
      • Я в подобных спорах довольно часто вставал на сторону CMS, основным моим аргументом был: "Ничего идеального нет, не нравится - не ешьте!". Но в данном случае ситуация двоякая. С одной стороны если разработчик не может повторить или "пощупать" баг, то его как бы и нет. Это аксиома. В данном случае, если не был дан изначально доступ к FTP (но его требовали), то претензии как бы несостоятельны.

        Если доступа к FTP не требовали, тогда, напротив, получается как в анекдоте:
        Цитата
        если бы программисты были врачами, им бы пациенты говорили например "у меня болит нога", а они бы отвечали "ну не знаю, у меня такая же нога, а ничего не болит"
        Выше Виталий писал
        Цитата
        Ну мы тоже не красны девицы вам, ошибок не делать. Могли что-то забыть-упустить
        с этим я согласен, но вспоминается один случай, когда выложили новую версию вечером. Я скачал, начал устанавливать, а дистр выдаёт ошибку. Отписал в ТП, кто-то тоже столкнулся и отписал в багтрекер, указав, что в установщике запятой не хватает. В 7 утра выложили исправленную версию.

        Это о чём говорит? О том, что перед выкладыванием даже не потрудились установить/проверить дистр, хотя это дело одной минуты. Т.е. отсутствует такое понятие как ОТК (в моём понимании).

        По поводу багтрекера. Вот в мае был у меня вопрос по редизайну админки (файлы при формировании новой темы затирались наполовину дефолтными). Я тему на багтрекере создал, параллельно тему на форуме, выложил все файлы, всё описал. И никакой реакции до конца ноября.

        Надо понимать, что на существенный редизайн админки у меня далеко не 5 минут ушло и вся работа коту под хвост из-за этой ошибки. Ошибку исправили, но с выходом 6-ки весь смысл проделанной работы потерялся. Всё-таки 7 месяцев не получить ни ответа ни комментария на элементарный вопрос "это баг или так задумано?", согласитесь, странно. Поэтому заявление
        Цитата
        Если же баг попадает в багтрек, конечно, рассматривается он приоритетно в ближайшие дни после публикации, какие там месяцы...
        тоже как-то двояко смотрится.

        Это я всё к чему? - на мой взгляд, не правы обе стороны. Поэтому надо пользователям охотнее идти на контакт (давать тот же доступ, если он нужен, сразу), с другой стороны разработчикам внимательнее относиться к проблемам пользователей.

    • 22 декабря 2015 г.
    • Цитата
      недальновидности утверждавших

      т.е. у Вас скорее всего связка nginx + apache, при этом к настройке сервера подошли не думая о переменных.
      А если у Вас был бы чистый nginx, то полагаю, что Вы кричали бы о несостоятельности cms, т.к. не работает .htaccess? Или Вы предлагаете разработчикам cms предусмотреть все возможные варианты настроек web серверов (а если самописный вебсервер)?
      •
      • 22 декабря 2015 г.
      • Не думаю что связка apache+nginx является редкой.
        Согласен с тем что CMS не обязана работать на всех подряд серверах, но нужно же учитывать, что они бывают разные, с разными настройками. Не для этого ли перед установкой запускается тест системы, сообщающий о её состоянии?
        Ну либо сообщите о том, что CMS работает только под Apache, с другими серверами не тестирована и возможны сбои. Некоторые CMS не стесняются говорить о том, что для них нужен особенный хостинг, с особенными настройками. Зато люди знают что лучше с ними не связываться :)))

        p.s. если бы у нас был самописный сервер, то и CMS у нас была бы самописная.
        •
        • 23 декабря 2015 г.
        • Цитата
          Не думаю что связка apache+nginx является редкой.

          На reg.ru так (на нектороых тарифах, по крайней мере). Не маленький хостинг, согласитесь.
  •
  • 15 января 2016 г.
  • Благодарю за уделённое время и решение вопроса. В последних версиях всё работает без необходимости дополнительных правок каких либо системных файлов CMS.
    •
    • 18 ноября 2016 г. , редакция: 18 ноября 2016 г.
    • ОНЛАЙН СОФТ (ONMASTER), насколько я понимаю, в настоящей версии CMS Diafan проблемы с настройкой доступа по протоколу HTTPS на сайтах нет?
      Просто на одном из ресурсов сравнения CMS Diafan и CMS WordPress информация об отсутствии на CMS Diafan доступа по протоколу HTTPS до сих пор присутствует!
      •
      • 18 ноября 2016 г.
      • Леонид, здравствуйте!
        Да, всё работает и у нас мы всем своим клиентам предлагаем размещаться именно по https настраивая это. Наверное, единственный минус заключается в том, что нужно делать принудительную переадресацию с http на https, т.к. Diafan может закэшировать и выдать на одной странице объекты с разными протоколами и получиться не очень.
  •
  • 29 ноября 2016 г.
  • Друзья, подскажите как мне подключить ssl сертификат? На хосте рег ру все подключено ключи сертификата корректно вставлены.
    Но не открывает сайт в HTTPS, хоть я и изменял .httacces согласно инструкции на рег ру.
    Когда проверял ssl на корректность, вот что выдало.
    Подскажите как решить эту проблему !!!!
    •
    • 29 ноября 2016 г.
    • 1) Купить
      2) Хостера Вашего сайта - попросить установить
      3) Всё готово

      недорогие сертификаты есть у Reg.RU
      https://www.reg.ru/ssl-certificate/

      тогда чтоб получить полный кайф и + в карму сайта (арендуйте выделенный IP под домен)
      •
      • 29 ноября 2016 г.
      • Есть бесплатные сертификаты ;) и все прекрасно работает.
        •
        • 29 ноября 2016 г.
        • Об отличии от платных напишите пару слов?
          •
          • 29 ноября 2016 г.
          • Я думаю отличия должны описывать те, кто за них денег хочет, чтобы было понятно за что. Нашим клиентам вполне достаточно бесплатных и пока просьб заменить их на платные не поступало. Сайты нормально открываются в браузерах. И да, редирект с http на https в нашем случае происходить на уровне настроек хостинга, а не через .htaccess, но это наверное дело вкуса и конкретных условий.
          •
          • 30 ноября 2016 г. , редакция: 30 ноября 2016 г.
          • Все очень просто. Прям в двух словах :)

            В реальности существует большое количество сертификатов, каждый из которых предназначен для определенных задач. Достаточно распространенный тип сертификатов - это SSL (Secure Socket Layer). В свою очередь этот тип сертификатов можно разделить на несколько видов: Code Signing, Website Anti Malware Scanner и Unified Communications.

            И так, SSL сертификат является распространенным средством поднятия защищенного канала связи. Поясню, чтобы защитить данные от перехвата (в том числе подмены) циркулирующие между сервером и клиентом (если хотите, то между веб-сервером или сайтом с одной стороны и браузером пользователя с другой стороны) используется специальный протокол HTTPS, который используется для передачи зашифрованных данных. А для того, чтобы заработал протокола HTTPS и нужен SSL сертификат.

            Также SSL сертификаты можно разделить на самоподписанные (self-signed) и не самоподписанные.

            Самоподписанный сертификат можно сгенерировать на веб-сервере или домашнем компьютере самостоятельно, то бишь бесплатно. И все будет достойно работать. Но такой сертификат предназначен для внутренних целей. Например, при создании защищенного канала связи между веб-камерами на вашей дачей и компьютером у вас дома (чтоб посторонний не подсмотрел). Поясню почему такой сертификат в основном для внутренних целей. Да потому, что Ваш браузер, обратившись к такому ресурсу, использующему самоподписанный сертификат, тут же покажет ошибку на весь экран. На самом деле такая ошибка означает, что браузер вас информирует, что подлинность сертификата невозможно проверить, так как он самоподписанный. Устранить такую ошибку можно двумя способами: первый, постоянно нажимать на такой странице "кнопку - ссылку" означающую - "продолжить соединение"; второй, установить такой сертификат в ваш браузер (секундное дело).

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

            Теперь о том, что храниться в SSL сертификате: полное (уникальное) имя владельца сертификата, открытый ключ владельца, дата выдачи сертификата, дата окончания сертификата, полное (уникальное) имя центра сертификации, цифровая подпись издателя.

            Теперь о том, что такое центр сертификации. Это доверенная организация (что то вроде нотариуса, который подписал бумажку, а мы верим), которая вправе выдать такой сертификат. То есть такая организация перед выдачей Вам сертификата проверяет Ваши исходные данные и гарантирует их достоверность. Наверно запутанно изложил, поэтому приведу простой пример. Допустим вы с домашнего компьютера решили посетить личный кабинет Сбербанка. Сервер банка в автоматическом режиме перебросил вас на защищенный канал связи. В работе такого канала связи используется сертификат, в котором написано, что это сертификат Сбербанка. При этом сертификат подписан не а бы кем, а организацией, которой мы можем доверять. Что же получилось в итоге. Например, я создал сайт-дубликат Сбербанка, поднял защищенный канал связи. При этом центр сертификации не поверил мне и мне пришлось сделать самоподписанный сертификат, в котором написал, что это сертификат Сбербанка. Но Ваш браузер не поверил самоподписанному сертификату и сообщил Вам. В итоге сертификат не только шифрует канал связи, но и позволяет убедится посторонним, что вы - это вы (как паспорт гражданина).

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

            Наиболее известные центры сертификации:
            Comodo - работает с 1998 штабквартира в Jersey City, New Jersey, США.
            Geotrust - основан в 2001, в 2006 продан Verisign, штабквартира Mountain View, California, США.
            Symantec - бывший Verisign в состав которого входит и Geotrust. Купил всех в 2010 году.
            Thawte - основан в 1995, продан Verisign в 1999.
            Trustwave - работает с 1995, штабквартира Chicago, Illinois, США.

            Таким образом самый крупный игрок в этом деле - это Symantec, который владеет тремя крупнейшими центрами сертификации - Thawte, Verisgin и Geotrust. Основное отличие между разными центрами сертификации - это цена за сертификат и в каком количестве браузеров установлен их корневой сертификат. То есть, если в браузере не будет корневого сертификата, то он (браузер) выдаст знаменитую ошибку.

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

            Теперь о видах SSL сертификатов. Между собой они отличаются свойствами и уровнем валидации.

            Cертификаты по типу валидации:
            - сертификаты, которые подтверждают только доменное имя (Domain Validation - DV);
            - сертификаты, которые подтверждают домен и организацию (Organization Validation - OV);
            - сертификаты, с расширенной проверкой (Extendet Validation - EV).

            Сертификаты с расширенной проверкой - это самые дорогие сертификаты. В таких сертификатах есть так называемый «green bar» - то есть при входе не сайт, где установлен такой сертификат в адресной строке браузера посетителя появится зеленая строка, в которой будет указано название организации, получившей сертификат. Например, https://nic.ru/ или https://thawte.com
            Такие сертификаты обладают наибольшим уровнем доверия, поскольку сертификат указывает, что компания реально существует, прошла полную проверку и сайт действительно принадлежит ей.

            Сертификаты по своим свойствам:
            - обычные SSL сертификаты (подтверждают только домен);
            - сертификаты SGC (с поддержкой повышения уровня шифрования, актуальны для древних браузеров и не пользуются популярностью, т.е. практически никому не нужны такие сертификаты);
            - сертификаты Wildcard (распространяется не только на основной домен, но и его поддомены - например, не только на diafan.ru, но и на cloud.diafan.ru);
            - сертификаты SAN (хорош, если вы хотите использовать один сертификат для нескольких разных доменов, размещенных на одном сервере);
            - сертификаты EV (с расширенной проверки и зеленой строкой в браузере);
            - сертификаты c поддержкой IDN (поддерживают работу с IDN доменами);

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

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

            В общем как-то так, успехов.
            •
            • 30 ноября 2016 г.
            • В итоге: если Ваш сайт описывающий жизнь Ваших тараканов в Вашей голове , день за днем... - можете и бесплатный ставить
              •
              • 30 ноября 2016 г. , редакция: 30 ноября 2016 г.
              • Ключевое слово
                Цитата
                Чаще всего
                Есть центры сертификации не взимающие плату.
            •
            • 30 ноября 2016 г.
            • ВИТАЛИЙ (NVGPRO) , а что вы можете сказать про вот такой сертификат.
              • 30 ноября 2016 г.
              • Цитата
                а что вы можете сказать про вот такой сертификат
                Что именно Вы хотите узнать? В его свойствах, изображение которых Вы привели, все описано.

                То есть информацию о сертификате вы можете увидеть в его свойствах. Поясню, существуют разные задачи организации удаленного взаимодействия клиента и сервера для которых используются соответствующие сертификаты и настройки программного обеспечения. Например, Вам достаточно только убедиться, что, обратившись по адресу http://diafan.ru/, Вы действительно попали на ресурс, принадлежащий именно diafan, а не на какой-то вредоносный сайт-двойник. Таким образом, можно не тратить ресурсы на шифрование канала связи, а ограничится только идентификацией (но это уже тонкости настройки софта). То есть все зависит от того как у Вас организованна работа защиты информации, включая взаимодействие с удостоверяющими центрами.

                Самое главное, что нужно знать большинству не искушенных в таких делах: работа cms и работа https ни как друг с другом не связана. То есть если у Вас не работает https, то совершенно не означает, что в этом виновата cms. А точнее, cms вообще здесь не приделах.
  •
  • 29 ноября 2016 г.
  • И ничего больше, вообще не знаю что делать, так как кодингом не владею.
    •
    • 29 ноября 2016 г.
    • Кодинг - Шкодинг Вам зачем?
      - В Самой CMS нечего трогать не надо!

Новости

  • Вышла очередная сборка DIAFAN.CMS 7.2.2
  • 18 июня
  • В сборке большое обновление demo-шаблона, дополнительная защита от спама, улучшение YML-импорта и еще много важного и интересного.
  • Не пропустите сборку DIAFAN.CMS 7.1.4
  • 24 апреля
  • В новой сборке совершили революцию в структурировании кастомизированной информации в шаблонах, добавили авторегистрацию пользователей, усовершенствовали защиту от спама, актуализировали накопительную скидку, а также улучшили производительность и стабильность работы системы.
  • Сборка DIAFAN.CMS 7.1.3
  • 12 января
  • После выхода сборки 7.1 мы выпустили уже три патча, в каждом из которых улучшаем административную часть сайта. Сборка DIAFAN.CMS 7.1.3 уже доступна к установке. 
Все новости

Форум

Перейти на форум