Как работать с частными / общедоступными изображениями созданной пользователем галереи изображений?
Сейчас я работаю над веб-проектом, где пользователи могут создавать галереи изображений и загружать картинки. По желанию они могут помечать фотографии как частные, чтобы никто другой не мог на них смотреть. Теперь я не уверен, как правильно реализовать механизм защиты. Конечно, у меня есть некоторые идеи, но ни одна из них не кажется оптимальной.
Вот одна из моих идей:
Создайте таблицу для пользовательских изображений:
image_key (PK) | user_id | public_image (boolean)
изображение будет сохранено на жестком диске с помощью iamge_key и может быть доступен через http по URL-адресу, который выглядит следующим образом:
http://www.myCompany.com/images/image_key
сервлет будет сопоставлен с URL-путем images , ключ будет извлечен, поток к файлу на жесткий диск будет openend, а picutre будет транслироваться.
Кроме того, перед контейнером сервлета будет обратный прокси-сервер для обеспечения некоторого кэширования.
Проблема с этим решением состоит в том, что мой serlvet должен был бы пойти в базу данных и проверить, является ли изображение с данным ключом открытым или нет. ,
Мой вопрос: Можно ли это сделать без попадания в базу данных? (некоторые модные идеи) Может ли кто-нибудь предоставить лучшее решение для хранения и отслеживания фотографий? Как бы выглядело решение, когда помимо общедоступных и частных картинок некоторые снимки передаются только для друзей?
Обратите внимание, что этот вопрос не касается хранения рисунков в базе данных или где-либо еще, а касается управления правами доступа к двоичным ресурсам в среда веб-приложения.
4 ответа
Если таблица БД правильно индексирована и вы используете пул соединений, то удар по БД будет дешевым. Я бы просто оставил все как есть. В крайнем случае, вы можете иметь копию таблицы в Map в области видимости приложения. Но это может съесть слишком много памяти сервера. Если вы используете ORM-фреймворк, например JPA/Hibernate, вы также можете просто включить кэш второго уровня, чтобы передать кэширование ORM. Как правило, он будет выполнять свою работу очень хорошо.
Что касается кэширования на стороне клиента, вы хотели бы иметь короткое время истечения (1 час?) и обеспечить doHead() в сервлете, который в свою очередь делает практически то же самое, что и doGet(), но без записи какого-либо бита в тело ответа. Вы также хотите проверить наличие заголовков If-None-Match и If-Last-Modified в сервлете, если клиент предоставил их. Вы можете найти здесь базовый пример сервлета, который делает это.
Другой альтернативой может быть сохранение такой информации в метаданных изображения .
API метаданных изображений: http://download-llnw.oracle.com/javase/1.4.2/docs/api/javax/imageio/metadata/package-summary.html
Вы можете найти связанные пример:
http://download-llnw.oracle.com/javase/1.5.0/docs/guide/imageio/spec/apps.fm5.html
Чтобы избежать частого обращения к базе данных, как насчет следующих шаблонов URL:
1. http://www.mycompany.com/images/<user_id>/public/<image_key>
2. http://www.mycompany.com/images/<user_id>/private/<image_key>
3. http://www.mycompany.com/images/<user_id>/shared/<image_key>
Для 1 очевидно, что поиск в БД не требуется - изображение может быть немедленно доставлено кому угодно. Для 2 ваш сервлет должен будет проверить, совпадает ли идентификатор активного пользователя с user_id в запросе - опять же, надеюсь, поиск в БД не требуется, просто проверка переменной сеанса.
Единственный случай, когда потребуется вызов БД, - это 3, чтобы проверить взаимосвязь между запрашивающим пользователем и пользователем, которому принадлежит изображение.
Конечно, вы должны быть очень осторожны с кешированием, чтобы гарантировать, что ваш кеш не обслуживает частные или общие изображения для неавторизованных пользователей ...
Мой вопрос: можно ли это сделать без попадание в базу данных? (некоторые причудливые idea)
Ага, вы можете сделать это, не обращаясь к базе данных. У нас есть что-то похожее, и мы просто хотели что-то поскорее внедрить.
Пользователь отмечает ресурс как частный или общедоступный, когда загружает его.
Мы делаем что-то очень простое:
общедоступные ресурсы имеют «tinyurl like» URL, скажем: abcd.org/aZ3tD (часть пункта ] very short tinyurl-link, так что людям, которые хотят вырезать / вставить / твиттер, не нужно использовать дополнительный слой bit.ly или tinyurl)
частные ресурсы не предназначены для использования общий или архивный, поэтому пользователям не важен URL-адрес вида: abcd.org/private/da499c3314e2fdce6a10a8b985489671971c187d
Первая часть этого URL-адреса - это идентификатор пользователя.
Таким образом, только пользователь da499c3314e2 (который должен войти в систему) может получить доступ к ресурсу fdce6a10a8b985489671971c187d
Вы просили каким-то образом сделать это, не обращаясь к БД, это должно сработать ...