Чистая установка возвращает 502 Bad Gateway

О, он всё ещё стоит за обратным прокси. Я нашёл шаблон и несколько разных способов настройки Discourse, продолжая использовать официальный метод установки.

Скоро я напишу руководство. На всякий случай, если кому-то ещё это понадобится, или если мне снова придётся это делать, ха-ха.

Есть лишь небольшая проблема: так как моя установка не использует SSL от Let’s Encrypt, в ссылке для активации электронной почты, которая была отправлена, использовался http вместо https. Хотя есть редирект со всех http на https, я бы хотел принудительно включить https на стороне бэкенда, чтобы все ссылки использовали https, а не http.

РЕДАКТИРОВАНО: нашёл

#ПРИНУДИТЕЛЬНЫЙ SSL
DISCOURSE_FORCE_HTTPS: true

Эм… у вас используется обратный прокси, так зачем же отправлять HTTPS на бэкенд?

Установка флага «принудительный HTTPS» указывает Discourse использовать HTTPS во всех ссылках на сам себя.

Да, но это не отвечает на вопрос «почему».

Это нужно для шифрования соединения.

WAN → Reverse Proxy = HTTPS
Reverse Proxy → Backend = HTTPS

Таким образом, если кто-то получит доступ к серверной комнате, он не сможет просто подключить Ethernet-кабель и увидеть трафик в открытом виде. Соединение останется зашифрованным по HTTPS, что усложнит жизнь злоумышленнику. Мне важно, чтобы вся цепочка работала по HTTPS: не WAN HTTPS → Reverse Proxy HTTP → Backend.

В противном случае это будет лишь иллюзия безопасности.

Zero Trust, даже если я знаю вас более 10 лет.

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

Всё настолько безопасно, насколько это возможно.

Разве вы не заметили, что большинство утечек происходит изнутри? Благодаря этому я уверен, что защита моего сервера непробиваема, и единственная уязвимость — это люди. Мои сотрудники это полностью понимают.

У меня есть несколько высокопрофильных пользователей облачных сервисов, и если по какой-то невероятной причине их данные всё же утекут, зная, что защита моего сервера надёжна, я смогу проверить камеры и точно определить виновника утечки.

Кажется, AWS действует схожим образом, судя по тому, что я видел. Человеческий фактор всегда должен быть в приоритете, независимо от того, насколько безопасен ваш сервер. Достаточно одного USB-накопителя, и всё кончено.

Потому что, если этого не сделать, например, будут отправляться ссылки на письма, ведущие по протоколу http, а не https, или ссылки на изображения с http вместо https. Эта настройка включена по умолчанию, если Discourse определяет, что используется https; я не до конца понимаю, почему она не установлена по умолчанию на данном этапе, поскольку Discourse в основном не работает, если есть какие-либо ссылки по http.

Речь не о соединении между обратным прокси и Discourse, а о ссылках, которые Discourse создаёт сам на себя.