Пользователь загружает в систему картинку с приватными данными (например паспорт). С

фронтенда загружается картинка, получается её uuid.
Делается запрос с uuid картинки на создание какого-нибудь ресурса, на просмотр которого у него (пользователя) будут права.
Проблема в том, что если другой пользователь угадает uuid уже существующей картинки и создаст свой ресурс с её (картинки) uuid - он сможет просматривать эту картинку.
Как можно решить эту проблему?

Мне в голову пришло только шифровать идентификаторы. Но никто так не делает вроде, поэтому я сомневаюсь

Сделай хранение связи картинка пользователь и при просмотре картинки проверяй, принадлежит ли картинка текущему пользователю или нет

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

использовать https://www.php.net/manual/en/function.random-int.php или https://www.php.net/manual/en/function.random-int.php если нужно минимизировать вероятность угадывания

Да uuid тоже попробуй угадай...

Из спеки: Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access), for example. A predictable random number source will exacerbate the situation.

В данном случае это будет тупой перебор

Имхо, вы напрасно смешиваете публичные картинки и картинки пользователей. У одних должна быть проверка прав, другим она не нужна, то есть нужно их гнать через немного разные точки входа, а то и вообще через разные механизмы и разные хранилища.

проверкой прав занимается приложение в зависимости от ресурса, в котором находятся картинки(точнее их идентификаторы). Соответственно если для ресурса нужна проверка прав - приложение это проверит, если не нужна - не проверит. Суть именно в том, чтобы отделить файлы сами по себе от конкретных ресурсов, в которых они используются. Т.е. в контексте загрузки файлов - картинка - это файл, у неё есть там расширение, оригинальное имя и т.п. В контексте подачи заявления куда-нибудь, например, файл - это паспорт в виде идентификатора, ссылающегося на файл.

А у random_int, значит, источник генерации числа неизвестный, да?

/dev/urandom по дефолту

Какая неожиданность!

> если другой пользователь угадает uuid уже существующей картинки Можешь представить себе uuid в виде 58bit идентификатора + 64bit ключа доступа. Я сомневаюсь, что вы забьёте все 58bit изображениями (это очень много в штуках) и ещё больше сомневаюсь, что обычный человек сбрутит 64bit ключ через http api интерфейс.

это да, я тоже сомневаюсь

сделать в ресурсе поле picture_uuid уникальным )

Мне тяжело понять, что есть ресурс. Я исходил из того, что это табличка resources в базе

это всё, к чему можно прилепить картинку. Заявление какое-то электронное с документами, профиль на сайте, карточка товара, что угодно

это записи в РСУБД или нет?

Я бы на вашем месте скорее думал что делать, если идентификатор утечёт. Вы не сможете отозвать доступ и предоставить новый. Максимум — удалить изображение с идентификатором полностью во всех ресурсах и запретить в новых. Вот для таких случаев действительно нужен отдельный access_token любой длины (с возможностью в дальнейшем длину увеличить). А вышеописанные случаи, имхо, не столь критичны.

ну да, токен с временем истечения