Галерея клиента: доступ к превью и оригиналам

У личной галереи может быть закрытая страница, но отдельно доступные изображения. Если проверка прав выполнена только при открытии альбома, она не обязательно распространяется на превью, оригиналы и готовые архивы. Поэтому при заказе галереи фотографу нужно определить доступ к каждому виду материала и проверить результат на собственных учебных аккаунтах. Наличие формы входа само по себе не подтверждает, что все файлы выдаются по нужным правилам.

В статье описан защитный сценарий проектирования и приёмки. Здесь нет поиска чужих фотографий или способов получать доступ к ним. Для проверки используют только свои тестовые альбомы с нейтральными изображениями и разрешённые среды. Материал не решает юридические вопросы публикации снимков и не обещает запретить копирование того, что человек уже получил законным способом.

Опишите, какие материалы действительно должны быть закрыты

У альбома обычно есть несколько представлений: обложка, небольшие изображения для просмотра, обработанные файлы, оригиналы и пакет скачивания. Конкретный состав зависит от выбранной системы. Перечислите его до обсуждения пароля или красивого окна входа. Иначе заказчик под «закрытым альбомом» будет понимать все материалы, а исполнитель — только HTML-страницу со списком кадров.

Для каждого вида запишите, кто может его получить и при каком состоянии заказа. Не предполагайте, что разрешение смотреть превью автоматически означает разрешение получать оригинал. Также не смешивайте доступ клиента и полномочия сотрудника. Менеджеру может быть достаточно состояния готовности, а не полного доступа ко всем материалам. Разграничение должно отражать реальные обязанности, а не один общий переключатель администратора.

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

Составьте матрицу ресурсов

Ниже — пример постановки задачи, а не универсальная политика для всех фотографов. Права и состояния следует заменить согласованными правилами конкретного проекта. Важно, чтобы в таблице были отдельные ресурсы, которые затем можно проверить, а не одна строка «личный кабинет защищён».

Матрица помогает отделить обещание интерфейса от поведения системы. Если кнопка «скачать оригиналы» скрыта, это описывает экран. Проверка того, кому система выдаёт оригинальные файлы, является другой частью приёмки. В рекомендациях OWASP отдельно рассматриваются проверки авторизации запросов и статических ресурсов. Это полезная опора для разговора с разработчиком о границах защиты.

Архив требует собственной проверки

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

Проверьте изменение состояния во время подготовки на учебных данных. Например, доступ закрыт ответственным сотрудником до того, как задача завершилась. Ожидаемое поведение нужно определить заранее: что будет с запросом, результатом и уведомлением. Не оставляйте этот случай на усмотрение последнего компонента, который сохранил файл. Иначе интерфейс покажет закрытый альбом, а сообщение отправит противоречащее ему предложение скачать пакет.

Состав архива тоже требует сверки. Временный выбор кадров, полный альбом и согласованный набор могут различаться. Для проверки сохраните учебный список ожидаемых файлов и сравните результат. Наличие успешно скачанного ZIP подтверждает получение какого-то архива, но не доказывает правильность его содержимого и прав адресата.

Что обсудить о хранении и кешировании

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

Документация MDN различает no-cache и no-store: для обычного HTTP-кеша первое требует проверки перед повторным использованием сохранённого ответа, второе запрещает хранить новый ответ соответствующему кешу. Поэтому название настройки «не кешировать» без точного смысла недостаточно. Возврат к странице через историю браузера является отдельным сценарием: не обещайте для него те же проверки только по этой директиве. При этом заголовок не заменяет авторизацию и не возвращает уже переданный человеку файл. Попросите разработчика объяснить политику для каждого вида ресурса, не распространяя её автоматически на весь публичный сайт.

Если интерфейс сохраняет материалы для работы без сети, возникает дополнительная задача очистки и изоляции данных. Для этого есть отдельный разбор кеширования после выхода в PWA. В личной галерее сначала установите, предусмотрено ли такое поведение вообще. Не обещайте офлайн-просмотр и строгое мгновенное исчезновение всех полученных копий одновременно без ясных ограничений.

Как понимать закрытие доступа

Запишите, какое событие означает закрытие: решение владельца, смена состояния проекта или другое согласованное действие. Затем определите эффект для новых запросов страницы, изображений и архива. Удалённая кнопка не считается результатом для всех ресурсов. Проверять нужно те каналы выдачи, которые были перечислены в матрице.

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

Если у проекта есть временные ссылки, их условия требуют отдельного описания. Не приравнивайте такую ссылку к обычной странице после входа. Укажите, что подтверждает право её получения, какой ресурс она открывает и как соотносится с выбранной политикой закрытия. Здесь не задаётся универсальный срок действия: он зависит от требований и фактической реализации.

Небольшой безопасный набор для проверки

Создайте два своих учебных клиента и два тестовых альбома. Для каждого заранее задайте разрешённый состав. Подготовьте нейтральные изображения разных размеров, чтобы отличать превью, готовый файл и оригинал без настоящих клиентских съёмок. Разработчик проводит предусмотренные проверки авторизации в разрешённой среде, а заказчик сверяет ожидаемые результаты по матрице.

Проверьте обычное получение разрешённого набора, отсутствие лишних материалов, подготовку архива и последующее закрытие доступа. Добавьте выход из аккаунта и новый вход другим учебным пользователем, если такой сценарий поддерживается. Не используйте чужие аккаунты и не переносите рабочие секреты в публичную задачу. Для фиксации результата достаточно безопасных идентификаторов тестов и наблюдаемого состояния.

Что должно остаться после приёмки

Попросите перечень проверенных ресурсов, краткую политику доступа и описание ограничений. Отдельно отметьте то, что не поддерживается: например, выдача оригиналов либо офлайн-просмотр. Это полезнее общего обещания «всё закрыто паролем». После добавления нового формата изображений или нового способа выгрузки соответствующую строку проверяют снова.

Назначьте владельца решения о публичном и личном составе. При изменении обложки, правил хранения или обработки архива он должен понимать, какие проверки повторить. Закрытая галерея является не одним экраном, а согласованной цепочкой выдачи материалов. Хорошая приёмка показывает её реальные границы и позволяет спокойно развивать сайт, не полагаясь только на то, что посторонний человек не видит кнопку.