Как правильно «послать» клиента

в 6:57, , рубрики: nginx, Plesk, ssl сертификаты, Блог компании Parallels, домены, хостинг, метки: , , ,

image
Давным-давно в нашей хостинг-панели Parallels Plesk Panel мы сделали такую интересную фишечку: если вводился адрес панели с указанием порта (8443), но без указания шифрования (https), то Plesk перенаправлял пользователя на адрес https://<server_hostname>:8443. Это было удобно. Кто-то к этому поведению привык. А кто-то — даже учел в своих процессах. В версии 11.5 мы заменили веб-сервер, обслуживающий сам Plesk, c lighttpd на nginx. И нечаянно сломали ту самую маленькую фишечку. Просто не смогли придумать, зачем бы она была нужна, и с новым веб-сервером ее не реализовали. Пользователям, обращавшимся по адресу http://<domain>:8443, стала показываться ошибка 400 — «Bad request».

Наши пользователи тут же напомнили нам, написав отзыв на forum.parallels.com (а мы читаем наш форум, да), — что ломать хорошие фичи и не давать ничего взамен — это плохо. Простите нас :) Вы скоро сможете увидеть в превью Parallels Plesk Panel 12.x, что мы ее вернули.

Зачем мы все это рассказываем? Хотим поделиться одним интересным use-case от наших пользователей, опубликованном на форуме Parallels и дополнить его.

Итак, допустим, хостнейм вашего сервера — panel.provider.com, и вы установили валидный SSL-сертификат для защиты Plesk. Теперь вы можете сказать своим клиентам:
"Чтобы попасть в панель управления хостингом, вам нужно просто дописать :8443 к имени вашего домена.
Например, example.com:8443"
. Далее «автомагически» клиента перенаправляют с http://example.com:8443 на httpS://panel.provider.com:8443, что избавляет клиента от просмотра ужасной и страшной ошибки про SSL-сертификат, выданный не для его домена, о попытке украсть его данные и прочие страшилки от браузеров. Ваш клиент видит «зеленую» адресную строку в браузере, не видит ошибок — и доверие к провайдеру вырастает.

Как же это все работает, и что с этим можно сделать еще

Вся магия скрыта в конфигурационном файле /etc/sw-cp-server/config, а именно — в строке:

    error_page 497 https://$hostname:$server_port$request_uri;

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

Как многие уже догадались, можно заменить переменную $hostname на определенный адрес. Таким образом мы избавляемся от жесткой привязки к хостнейму сервера. Только править наш конфигурационный файл — это очень плохая идея, так как, скорее всего, последующие обновления Plesk не смогут корректно установиться из-за того, что конфигурационный файл был изменен. Поэтому мы сделаем свой файл, в котором просто переопределим эту инструкцию. Создадим файл /etc/sw-cp-server/conf.d/zzz-myhost.conf со следующим содержимым:

    error_page 497 https://panel.provide.com:$server_port$request_uri;

перезапустим sw-cp-server

    /etc/init.d/sw-cp-server restart

Таким образом, все пользователи будут отправлены по адресу https://panel.provider.com:8443 вне зависимости от хостнейма сервера.

Плюшка+

А для тех, кто не любит работать в консоли и напрямую править конфигурационные файлы, мы написали расширение, выполняющую для вас эту работу. Особенно это может пригодиться тем, кто активно использует Custom View и у кого нет root-доступа к серверу.
Единственный минус этого расширения — настройки автоматически не применяются. Поэтому необходимо перезапустить сервис sw-cp-server или перезагрузить сервер полностью.

Писать расширения для Plesk'a очень просто. Все подробности есть в документации.

Ссылки

По каким функциям Plesk скучаете вы?

Автор: sugdyzhekov

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js