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

Я использую Node.js, поэтому я попытался использовать промежуточные продукты Express для ограничения мультимедийных файлов пользователем, но я заметил, что это не лучший способ справиться с этим, поскольку экспресс не подходит для рендеринга статического контента.

Вот несколько вариантов, которые я могу придумать после нескольких сеансов Google

  • Корзина Amazon S3, в которой каждый пользователь получает свою собственную папку / разрешения и файлы, в нее нет (но являются ли файлы действительно конфиденциальными, когда у нас есть URL-адрес)
  • Создайте временный URL-адрес файлов, используя предварительно подписанные URL-адреса из корзины S3 (файл будет общедоступным в течение 20 минут, я не хочу этого)
  • Ограничить доступ к Nginx (опять же, я не знаю, может ли Nginx получить доступ к базе данных и аутентифицировать полученный запрос)
  • Использовать GridFS с mongoDB? (я, вероятно, не буду использовать это, но хочу посмотреть, может ли это быть решением)

Есть ли другой способ сделать это?

1
Syed Faizan 22 Дек 2016 в 19:33
Ваш контент не статичен, если он зависит от того, кто вошел в систему. Самый простой способ - написать собственный код, который проверяет права доступа, а затем загружает файл с диска. Нет ничего плохого в том, чтобы написать собственный код загрузки файла на node.js или на любом другом языке. О производительности следует беспокоиться только , когда это становится проблемой.
 – 
freakish
22 Дек 2016 в 19:48

2 ответа

Лучший ответ

Каждому пользователю дается уникальный идентификатор, в котором контент (файлы, видео и т. Д.) Частично ссылается на этот идентификатор, так что клиентам предоставляется доступ только к содержимому их идентификатора.

Пользователь входит в систему, nodejs связывает этого пользователя с его уникальным идентификатором, полученным из mongodb. Не нужно выгружать это на nginx. То, где вы храните контент, не зависит от этой логики. Может быть локальная файловая система, mongo, S3 и т. Д.

Избегайте ввода имени пользователя или идентификатора в любой URL-адрес, его избыточный сервер поддерживает эти знания внутри. Не надо путать URL. Например, Amazon AWS имеет этот URL, когда я взаимодействую со своим частным контентом.

https://console.aws.amazon.com/route53/home?#resource-record-sets:ZAHKXPA7IKZ8W

Смотрите, он просто показывает идентификатор контента, который уникален для ресурсов моего имени пользователя. Цель состоит в том, чтобы свести к минимуму беспорядок в URL.

В качестве альтернативы, в мире совместного использования ресурсов, например, при мерцании, здесь URL-адрес дает имя пользователя и идентификатор ресурса https://www.flickr.com/photos/okinawa-soba/31419099190/in/photostream/ В вашем случае, даже если кто-то получит URL-адрес другого контента, сервер должен отклонить так как он не уполномочен гадить с чужим контентом

1
Scott Stensland 1 Фев 2017 в 17:12
Это тоже работает ... что, если URL-адрес выглядит как /:username/:filename, и я настраиваю маршрут GET и добавляю промежуточное ПО, проверяющее сеанс, а также имя пользователя в маршруте (то же, что и сеанс). это тоже должно работать нормально, не так ли?
 – 
Syed Faizan
22 Дек 2016 в 23:18

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

Однако я не уверен, что это будет наиболее эффективный способ.

Если серьезно, я бы предложил использовать промежуточное ПО express.static вместе с Passport или чем-то еще для реализации аутентификации и разрешений. Здесь вы не «рендерируете» какой-либо статический контент. Вы просто транслируете файлы прямо с диска.

1
rsp 22 Дек 2016 в 20:06
Может express.static управлять нагрузкой, даже когда пользователей несколько тысяч? (не одновременно)
 – 
Syed Faizan
22 Дек 2016 в 23:15
Не понимаю, почему не могло. См. этот ответ, где я провел несколько тестов с http-server, и я получил 10000 одновременных подключений без проблем. Не думаю, что express.static здесь будет иначе.
 – 
rsp
27 Дек 2016 в 21:28