Здравствуйте.
У нас установлена версия Discourse v2.4.0.beta2 +346, которая изначально была доступна по адресу include.metaring.com.
В конфигурации использовался Apache HTTP Server на Ubuntu, который:
- Перенаправлял все HTTP-запросы на HTTPS
- Самостоятельно управлял SSL-сертификатом (LetsEncrypt)
- Все запросы перенаправлялись через прокси с использованием nginx http sock, поэтому порты Docker для Discourse 80 и 443 отключены/не используются
Мы выполнили следующие команды:
./launcher enter app
rails c
[1] pry(main)> SiteSetting.force_https = true
=> true
Это было сделано для того, чтобы быть абсолютно уверенными, что весь контент предоставляется по HTTPS (без этого возникало несколько ошибок).
Всё работало корректно.
Затем мы решили переместить приложение (не затрагивая базу данных и другие компоненты) в подкаталог include.metaring.com/discourse. Для этого мы отредактировали файл app.yml следующим образом:
DISCOURSE_HOSTNAME: include.metaring.com<— Без изменений, как и раньшеDISCOURSE_RELATIVE_URL_ROOT: /discourse
Чтобы быть абсолютно уверенными, мы выполнили:
./launcher stop app
./launcher destroy app
./launcher cleanup
./launcher rebuild app
Разумеется, мы также добавили в конфигурационный файл Apache правила для корректной работы ProxyPass от /discourse к unix:/../../nginx.http.sock|http://localhost/*discourse*.
После этого приложение, конечно, стало доступно онлайн, но возникло множество проблем:
-
Весь статический контент (плагины, ресурсы, изображения, JavaScript-файлы, загрузки) был недоступен. После долгих сеансов отладки и бесплодных поисков в интернете, чтобы заставить их работать, мы создали в Apache правила прокси для туннелирования их к корневому пути localhost без префикса /discourse (например, /disourse/plugins перенаправляется на > unix:/../../nginx.http.sock|http://localhost/plugins и так далее).
-
Некоторые пути /uploads на веб-страницах указывались без префикса /discourse, поэтому нам пришлось написать ещё одно правило прокси в Apache для перенаправления из /uploads/ в unix:/../../nginx.http.sock|http://localhost/discourse/uploads.
-
Теперь самое странное: когда клиент отправляет запросы, содержащие /uploads/default/ или /discourse/uploads/default/ (статический контент), нам нужно следовать решению, описанному в пункте 1, и перенаправлять их оба в
http://localhost/uploads/default/(без префикса /discourse), в то время как другие запросы /uploads/ или /discourse/uploads/, не содержащие префикс /default в пути, должны перенаправляться вhttp://localhost/discourse/uploads/(обратите внимание: отсутствие пути default означает, что это вызовы веб-сервисов).
С всеми этими 9 правилами прокси, которые мы добавили, всё снова работает корректно даже под путём /discourse. Но нам кажется крайне странным, что нам пришлось писать весь этот код, чтобы всё заработало снова.
Делаем ли мы что-то не так?
Существует ли какой-либо другой умный способ управления этой ситуацией?
=== РЕДАКТИРОВАНИЕ ===
Забыли упомянуть ещё одну вещь, возможно, связанную с этим:
Когда пользователь пытается загрузить собственное изображение для использования в качестве личного аватара, загрузка проходит успешно, и миниатюра изображения отображается корректно.
Однако при нажатии кнопки Сохранить изменения и перезагрузке страницы аватар возвращается к аватару пользователя по умолчанию
.
При проверке файла
produciton.log видно, что ошибка имеет код 418.Загрузка других изображений работает нормально.
Заранее спасибо за ответы и за вашу замечательную работу!