Не работают плагины оплаты от Webasyst

Приветствую!

Не корректно работают следующие плагины оплаты от Webasyst:

https://www.webasyst.ru/store/plugin/payment/priva...

и

https://www.webasyst.ru/store/plugin/payment/liqpa...

Суть проблемы в том что на сайте с нормально настроенным https и автоматическим редиректом на уровне сервера с http на https не приходят ответы от платежных систем так как они обращаются по адресу: http://mysite.com/payments.php/liqpay/ а там они естественно ловят 301 редирект на https://mysite.com/payments.php/liqpay/



Кто знает, подскажите пожалуйста где в коде можно изменить чтобы урл генерило с https



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

И вообще в связи с тем что поисковики скоро будут требовать о екомерса поголовно https странно что у Webasystа с ним такие проблемы, нигде нельзя явно нигде указать что магазин на https и все ссылки кругом должны быть с https.

3 ответа

  • 0

    Включить в настройках магазина использование https соединения для оформления заказа.

  • 1
    Дмитрий 24 июня 2015 13:58 #

    Сергей, спасибо за ответ, но не вариант. Функция о которой вы говорите предназначена для того если у вас весь сайт на http, а вы хотите чтобы оформление заказа у Вас принудительно редиректилось на https.

    Если у Вас весь сайт на https и стоит редирект с http на https на уровне сервера, то включив данную опцию корзина будет выдавать ошибку:

    "На этой странице обнаружена циклическая переадресация

    ERR_TOO_MANY_REDIRECTS"


    Нужно чтобы плагины оплаты, Приват24, Ликвепей, ВебМоней и прочие отдавали платежной системе урл для ответа https://mysite.com/payments.php вместо http://mysite.com/payments.php

  • 0

    Отключите "редирект с http на https на уровне сервера". Будет работать по всем протоколам. И еще вопрос, что там за настройка "на уровне сервера", которая циклит редирект…

    • +1
      Дмитрий Дмитрий 24 июня 2015 14:45 #

      Нельзя отключать редирект с http на https на уровне сервера. Появятся дубли страниц с http на https. И это в принципе противоречит правилам использования https и pci dss.

      На сервере ничего особенного не настроено, стандартный nginx который делает 301 редирект с http на https.

      • +1

        дубли поисковик отлично склеит, они понимают. ладно. неважно. раз pci dss.

        Чего же стандартный nginx с https на https редиректит?

        А, блин. знаю отчего. Было такое. Проверьте, какие заголовки и переменные окружения nginx выставляет при ssl соединении. Вебасист их кроме порта еще детектит по заголовкам и переменным окружения. Я у одного клиента нашел вот такой вариант: https://github.com/webasyst/webasyst-framework/pul...


        • +1
          Дмитрий Дмитрий 24 июня 2015 15:11 #

          Мне кажется глупо оставлять вообще открытым http если есть https. Да и заставлять поисковик склеивать дубли не благодарное дело. Тем более что все поисковики говорят о том что нужно переходить на https.

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

          А сейчас я был очень благодарен за костыль, который поможет отдавать страницу https://mysite.com/payments.php с https.

          • +1

            Говорю же — посмотрите, как ngix обозначает SSL соединение.

            Поставьте приложение Developer. Откройте админку через https. В окне приложения где можно PHP-код задавать либо var_dump($_SERVER), ливо вообще phpinfo() напишите. Нужна переменная, которую ngix устанавливает.

            Исправьте во фреймворке метод опредения SSL (см. выше по ссылке), чтоб он учитывал вашу настройку.

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

            Ну или мне доступ по SFTP, доступ к админке и $10 в случае успеха :))

            • +1
              Дмитрий Дмитрий 24 июня 2015 15:51 #

              Сергей, огромное спасибо. Таки да в связки nginx-apache передавались не правильно хидеры.

              Мой случай: http://habrahabr.ru/post/142363/ и все заработало как надо.

              • +1

                Дополню: большинство плагинов использует единый метод получения URL для callback запросов. Без дополнительных параметров возвращается URL с тем же типом, что и текущая страница (на основе заголовков запроса, доступных в PHP).

                Ошибки часто бывают при использовании связки nginx-apache, когда не корректно настроены передаваемые заголовки (header) запроса. Проверить, что https детектируется можно методом waRequest::isHttps(); а если этого не происходит, то посмотреть следы https в заголовках: var_exprt(waRequest::server());

                И если следов нет совсем, то проблема в некорректной настройке связки. Если следы есть, то они, скорее всего, оказались нестандартными и в методе не оказалось случая этих заголовков. Более правильным, по возможности, будет настройка связки. Либо сообщить нам, что есть экзотические случаи (с примером заголовков).


                • +1

                  Сообщили. А толку? pull-request из коммента выше уж месяц пылится... :) Понятно, что можно перенастроить сервер, но только если есть возможность. Того у кого shared, хостер просто нафиг пошлет и скажет, что у остальных все работает. :(

Добавить ответ

Чтобы добавить комментарий, зарегистрируйтесь или войдите