Может ли бэкенд каким-то образом преобразовывать все неполные ссылки в постах (например, example.com) в ссылки с протоколом https (https://www.example.com)??
Кажется, что они преобразуются в ссылки с http://, что приводит к различным проблемам, когда исходящие запросы к http://example.com не удаются у многих пользователей, переходящих по ссылкам из поста.
(Или, возможно, проверять сгенерированный целевой адрес и корректировать его на правильный протокол для доступа к нему?)
Спасибо, это мой первый вопрос, извините, если он повторяет предыдущие, но я не нашёл ничего, что кратко объясняло бы это.
mitch
Пожалуйста, нет. В интернете много сайтов, использующих HTTP, потому что им просто не нужен SSL.
Неужели это ещё одна рутинная задача по поиску и замене? Или я снова всё неправильно понимаю?
иррациональная паническая атака
К тому же меня беспокоит довольно специфическая ситуация: когда Discourse работает на своём VPS, а перед ним находится другой VPS с обратным прокси-сервером. Они часто будут общаться друг с другом без SSL.
Но это совершенно другая ситуация, верно? Однако я начинаю нервничать каждый раз, когда какое-то значение по умолчанию может измениться и сбить мои привычные сокращения…
Я думаю, вы ошибаетесь, утверждая, что этим сайтам не нужен HTTPS. Сейчас нет оправдания тому, чтобы не сделать ваш сайт безопасным.
Однако, похоже, я ошибался, считая, что это должно быть предложением по улучшению. Принудительный переход на HTTPS должен обеспечивать браузер, а не Discourse.
Я почти уверен, что современные браузеры по умолчанию отдают приоритет HTTPS перед HTTP.
Кроме того, многие веб-сайты на стороне сервера перенаправляют на HTTPS или используют заголовок HSTS.
Я не считаю, что ошибаюсь, когда речь идёт о реальности.
Необходимость шифрования соединений между серверами с помощью SSL, когда передаваемые данные не содержат ничего, что требовало бы защиты, — это тема для отдельного обсуждения. Но здесь это совершенно не по теме.
Однако говорить пользователям: «Извините, вы не можете добавить ссылку, потому что сторонний ресурс не использует порт 443» — это просто плохая идея. Не задача администратора или даже платформы Discourse диктовать, что кто-то должен или обязан делать.
Да, если HTTPS доступен. Некоторые домашние роутеры/модемы настроены на использование только HTTPS, и это действительно раздражает. Дело в том, что не каждый сайт следует желанию Google использовать SSL повсеместно, а отчасти потому, что многие платформы до сих пор обслуживают старые ссылки через HTTP, а эти глупые устройства не могут переписать URL.
Поэтому прежде чем обсуждать какие-либо функции, нужно сначала создать отдельную тему на форуме: является ли обязанностью платформы форума принуждать к использованию SSL для исходящих ссылок.
После этого техническое решение, насколько я понимаю, довольно простое — но опять же, я не разработчик.
Но вернёмся к теме.
Так что поиск и замена — это не срочное решение? Но я сейчас не совсем понимаю… снова… является ли реальная проблема тем, как Discourse автоматически формирует ссылки, если дан просто обычный URL? Если так, то я немного отступаю: да, автоматически должна использоваться HTTPS — но при этом ссылка должна быть редактируемой.
Проверка возможности использования http (и https с аналогичной функцией) только с помощью заголовка целевой страницы, код скопирован с:
def check_http_url(url)
http_url = "http://#{url}"
begin
uri = URI.parse(http_url)
connection = Net::HTTP.new(uri.host, uri.port)
request = Net::HTTP::Head.new(uri.request_uri)
response = connection.request(request)
if response
return true
else
return false
end
rescue
return false
end
end
Таким образом, с помощью этого кода (переведённого на Ruby, если я не ошибаюсь), бэкенд Discourse мог бы определить, является ли цель частичной ссылки, указанной в посте, https или http, а затем (с приоритетом для https) открыть правильную целевую ссылку для пользователя?