Перенос сайта за прокси: favicon и заголовок больше не используют https

Поддержка
1

С тех пор я перенёс свой экземпляр Discourse на другой сервер, и теперь он работает за обратным прокси с завершением SSL.

Однако изображение заголовка и фавикон запрашиваются не по HTTPS и блокируются. Я попытался включить опцию «принудительный HTTPS», но это не помогло.

image

2

Предоставляет ли ваш прокси заголовок X-Forwarded-Proto? (Должен).

3

Предоставляет ли ваш прокси заголовок X-Forwarded-Proto? (Это должно быть так).

Да, предоставляет.

4

У меня была та же проблема. У меня есть экземпляр Discourse за HAProxy с окончанием SSL. Исправление довольно простое, но неочевидное:

  1. Сначала убедитесь, что в настройках включена опция «force https» (перейдите в Настройки и отфильтруйте по «force https»).
  2. Перейдите в Настройки > Брендинг > и просто повторно загрузите свои логотипы.
  3. Теперь всё должно использовать HTTPS (обязательно нажмите кнопку обновления в браузере).

(Думаю, это может быть ошибкой в Discourse)

5

Здравствуйте,
Я хотел бы вернуться к этой проблеме. У меня возникла та же проблема, и я не могу установить force_https в true, так как войти в систему невозможно (ошибка «Неизвестная ошибка» при входе).
Как можно заставить логотип загружаться по протоколу https, а не http?
Разве это не должно быть просто?
Большое спасибо за вашу помощь (я потратил на решение этой проблемы много часов).

6

Вам нужно переключить настройку сайта force_https, подключившись к серверу по SSH и открыв командную строку Ruby. Здесь есть темы howto о том, как это сделать.

7

Спасибо за ваш ответ. Я, безусловно, был недостаточно ясен в своём сообщении. На самом деле, я могу изменить параметр force_https с помощью команды Rails, это не проблема. Поэтому, чтобы прояснить ситуацию:

До последнего обновления, которое я выполнил несколько дней назад и которое требовало пересборки контейнера Docker, у меня работало полное решение с параметром force_https, установленным в true, и с применением следующего патча в секции server файла конфигурации nginx для обеспечения корректного входа в систему:

  if ($http_x_forwarded_proto = 'http'){
    return 301 https://$host$request_uri;
  }

Это работало. Однако после обновления тот же патч больше не позволял мне войти в систему, выдавая известную ошибку «Unknown error».

Вот трассировка из производственного лога:

 Started POST "/session" for 193.134.222.4 at 2020-05-14 19:24:40 +0000
 Processing by SessionController#create as */*
 Parameters: {"login"=>"rossierd", "password"=>"[FILTERED]", "second_factor_method"=>"1", "timezone"=>"Europe/Zurich"}
 Can't verify CSRF token authenticity.
 Rendering text template
 Rendered text template (Duration: 0.0ms | Allocations: 1)
 Filter chain halted as :verify_authenticity_token rendered or redirected
 Completed 403 Forbidden in 2ms (Views: 0.7ms | ActiveRecord: 0.0ms | Allocations: 1101)

Учтите, что наш контейнер Discourse работает на виртуальной машине, доступ к которой осуществляется по протоколу HTTPS.

Есть ли у вас какие-либо идеи относительно причины изменения поведения до и после обновления?

На данный момент я отключил force_https, установив его в false. Всё работает нормально, за исключением логотипа в левом верхнем углу (брендового логотипа), который отображается некорректно, поскольку к нему осуществляется запрос по протоколу http://…

Кстати, вот URL нашего сайта: https://discourse.heig-vd.ch

8

Кроме того, я также обнаружил следующую настройку сайта, содержащую проблемный URL: SiteSetting.site_favicon_url (также существует SiteSetting.site_apple_touch_icon) со значением “http://…jpeg”. Однако, похоже, неочевидно, как изменить это значение с помощью простой команды rails, как это делается, например, для force_https.

9

Пожалуйста, есть какая-то помощь по этой теме?

10

Вы устанавливаете их через мастер настройки. Запустите мастер настройки заново и повторно загрузите изображения.

11

Я настроил изображения именно так. Я снова запустил мастер, но результат в конце остался прежним :frowning:
Похоже, что загрузка картинок не влияет на то, как на них ссылаются; это скорее связано с генерацией веб-страницы.

12

Что ж, после стольких неудачных попыток я наконец понял, как обеспечить корректный вход с force_https=true.

В окружении Docker я внес следующие изменения в файл /etc/nginx/conf.d/discourse.conf:

…
location @discourse {
limit_conn connperip 20;
limit_req zone=flood burst=12 nodelay;
limit_req zone=bot burst=100 nodelay;
proxy_set_header Host $http_host;
proxy_set_header X-Request-Start “t=${msec}”;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https; # $thescheme; ← Что я изменил
proxy_pass http://discourse;
}
…

И это единственно работает в этом разделе, по крайней мере в моей среде.

Теперь всё отлично работает!