Для полностью приватного форума (без анонимного доступа) отсутствие безопасного варианта для медиафайлов в конфигурации локального хранилища по умолчанию, на мой взгляд, является огромным упущением. Меня бы не удивило, если бы многие, кто запускает приватные форумы, не осознавали, что все вложения к их сообщениям общедоступны (если известен URL). Если текст моего сообщения нельзя прочитать анонимно, интуитивно кажется, что и вложения к нему тоже должны быть недоступны.
Стоит ли создать запрос на добавление этой функции, чтобы оценить уровень поддержки? Уже существует ли такой запрос? Именно эта проблема в настоящее время является решающим фактором для нашей небольшой и небогатой группы, которая пытается развернуть Discourse в среде, где у нас уже есть собственное оборудование для хостинга, и мы не хотим платить за облачное хранилище (особенно по ценам AWS S3) только для того, чтобы гарантировать, что наши медиафайлы не будут доступны анонимно.
Также, пожалуйста, простите меня за возможную наивность этого вопроса. Но разве уже есть поддержка отдельных бакетов для загрузок и резервных копий? Было бы сложно добавить поддержку третьего бакета для защищенных загрузок? Публичные загрузки попадают в публичный бакет, защищенные — в защищенный, и отдельные ACL для объектов не требуются. А если статус безопасности объекта изменится, его можно будет просто переместить между бакетами?
Я думаю, это довольно много работы. По крайней мере, день работы, но, возможно, и неделя?
Хостинг Cdck, который финансирует разработку, использует S3 для загрузки файлов, поэтому интерес представляют только саморазмещённые сайты, требующие только входа в систему и не имеющие бюджета на S3.
Если ваши пользователи видят ссылки на ваши ресурсы, они могут просто загрузить их и поделиться ими. Это не кажется большой проблемой.
Я не сума, что считаю странным, что текст поста защищён, а вложения — нет, верно?
Однако есть большая разница между умышленным и случайным распространением. Очевидно, что предотвратить первое действительно невозможно. Но второе может происходить прямо сейчас просто потому, что люди не понимают лежащие в основе технологии. Рассмотрим уведомления по электронной почте о постах, содержащих ссылки на вложенные изображения, которые по неосторожности пересылаются неучастникам. Опция удаления вложений из писем, не привязанная к функционалу защищённых медиа, могла бы стать хорошей альтернативой.
Даже когда люди намеренно делятся ссылками на вложения, они могли просто забыть, что ссылка относится к защищённой категории. Но в идеальном мире ссылка на вложение должна быть бесполезна для любого, у кого нет доступа к этой категории.
Текущая или будущая ошибка в одной из реализаций S3 также потенциально может позволить анонимный перебор ресурсов в бакете или возможность угадывать и подбирать URL-адреса объектов. В идеальном мире я бы хотел, чтобы мой локальный интерфейс S3 был изолирован от всего интернета фаерволом, чтобы к нему мог обращаться напрямую только сервер Discourse.
Не сошли с ума. Реализация безопасной загрузки для настроек, отличных от S3, определённо не является чем-то, против чего я бы возражал. Просто у нас нет срочности или давления для реализации этой функции, а изменения нетривиальны.
У нас периодически появляются стажёры и проекты на прослушивание, и это определённо тот тип задач, который мог бы подойти для одной из таких категорий.
У меня есть быстрое решение, которое, как я считаю, обеспечит безопасную загрузку файлов для сайтов, требующих авторизации.
В целом, нужно настроить Authentication Based on Subrequest Result | NGINX Documentation для загрузок. Единственная проблема в том, что я не могу найти URL, который возвращал бы 403/401 при включенной требовательности к входу, поэтому при попытке доступа к загрузке без авторизации возникает ошибка 500. Это произойдет только в том случае, если у кого-то будет URL загрузки и он попытается получить к нему доступ, не войдя в систему, так что это не кажется слишком серьезной проблемой.
Это что-то вроде этого:
# JP
location = /auth {
internal;
proxy_pass http://discourse/categories;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
proxy_set_header X-Original-URI $request_uri;
}
# END JP
location ~ ^/uploads/ {
auth_request /auth; #$JP
# ПРИМЕЧАНИЕ: очень раздражает, что мы не можем просто определить заголовки
# на верхнем уровне и наследовать их.
#
У нас нет планов по созданию отдельного функционала для защищенных загрузок, а также по обеспечению работы защищенных загрузок в средах, отличных от S3, или в средах без ACL. Возможно, мы рассмотрим возможность реализации этого в будущем, если спрос на данную функциональность достигнет уровня, при котором будет целесообразно выделить время и ресурсы на её разработку.
Почему используется https://hashhackersforum.s3.us-east-2.amazonaws.com/optimized/2X/3/3204e85df407adfce19e105308248aee8b3b3f57_2_690x424.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAU5WBGG5Z7FNHQEIS%2F20210415%2Fus-east-2%2Fs3%2Faws4_request&X-Amz-Date=20210415T025617Z&X-Amz-Expires=300&X-Amz-SignedHeaders=host&X-Amz-Signature=15c9118929ccd9c24a9594ab02a47e900269b9d921d41679a317e29d6174c2bc вместо https://forum.cdn.hashhackers.com/optimized/2X/3/3204e85df407adfce19e105308248aee8b3b3f57_2_690x424.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAU5WBGG5Z7FNHQEIS%2F20210415%2Fus-east-2%2Fs3%2Faws4_request&X-Amz-Date=20210415T025617Z&X-Amz-Expires=300&X-Amz-SignedHeaders=host&X-Amz-Signature=15c9118929ccd9c24a9594ab02a47e900269b9d921d41679a317e29d6174c2bc, хотя я правильно указал URL CDN?
Мне не проблема игнорировать это, но у нас включена функция защищённых медиафайлов (secure_media), что делает невозможным использование CDN. Это сообщение, вероятно, не должно отображаться на сайтах с включённой опцией secure_media.
После обновления до версии 2.8.0.beta1 мои значки, использующие аутентифицированные URL-адреса S3, перестали работать. До обновления всё было в порядке.
Я проверил таблицу uploads, и значение в столбце secure равно true.
Ах… ещё одно место, которое делает загрузку изображений безопасной там, где это не нужно. Значки не должны помечаться как безопасные, поскольку они, по сути, являются публичными изображениями, как аватары, логотипы категорий и другие элементы. Мне потребуется внести исправление, чтобы изображения значков не помечались как безопасные, а также написать скрипт миграции для исправления тех, которые уже помечены как безопасные.
Меня удивляет, что у вас это вообще работало, ведь в версии 2.8.0 ничего не должно было влиять на это.
Спасибо за ответ. Я впервые использую Ruby и восхищаюсь тем, насколько чистым и понятным может быть этот язык. После нескольких часов отладки я, кажется, понял, куда смотреть. Похоже, я сделал всё наоборот по сравнению с твоим советом Я добавил несколько строк в модель Badge, и теперь она может загружать изображения. Также я заметил, что там есть флаг for_site_setting. Думаю, он использует эту информацию для настройки ACL объектов в S3, и мне нужно установить для этого столбца значение false.
app/models/badge.rb
def image_url
if image_upload_id.present?
return upload_cdn_path(image_upload.url) if !image_upload.url.include?(SiteSetting.Upload.absolute_base_url)
uri = URI.parse(image_upload.url)
Rails.application.routes.url_for(
controller: "uploads",
action: "show_secure",
path: uri.path[1..-1],
only_path: true
)
end
end
Я изучу, какие изменения будут в следующем обновлении, чтобы больше узнать об этом.
Не мог бы ты подсказать, какую версию лучше использовать в продакшене?
Спасибо!
Надеюсь, в будущем смогу внести больший вклад в кодовую базу.
Твоё изменение в модели бейджей, безусловно, сработает, и здорово, что тебе удалось это реализовать с первого раза при работе с Ruby! Однако я всё же исправлю основную проблему: бейджи не должны помечаться как безопасные.
Наша ветка tests-passed — лучший вариант для продакшена, так как она получает все последние исправления сразу после их выпуска. Хотя некоторые предпочитают оставаться на бета-ветке, которая обновляется исправлениями и изменениями примерно раз в несколько недель.
Дам знать, когда исправление для помеченных как безопасные бейджей будет готово.
…но задаюсь вопросом, не связана ли проблема с вашим комментарием здесь?
Поддерживается ли загрузка аватаров пользователями, когда включена безопасная загрузка медиафайлов? На данный момент я получаю ошибку, но интересно, не связано ли это с тем, что аватары загружаются в тот же бакет, где публичный доступ не разрешён…
1 лайк
Canapin
(Coin-coin le Canapin)
Разделил(а) эту тему
126
Недавно я переименовал «secure media» и связанные с ним настройки в «secure uploads», поскольку это касается не только изображений и видео и т. д., и все обычно называют это «secure uploads». Соответствующий коммит ядра находится здесь:
Первый пост этой темы теперь обновлён с учётом этого изменения.
Я добавил несколько строк в модель Badge, и теперь она может загружать изображения. Также я заметил, что там есть флаг for_site_setting. Думаю, он использует эту информацию для настройки ACL объектов в S3, и мне нужно установить для этого столбца значение false.