1. object еще не создан, его id мы не знаем
2. но мы в форму уже грузим файлы
3. файл грузится во времянку где ему дают уникальное имя USERID_md5(file).EXT
4. когда форму заполнят то эти временные имена поедут в логику создания object
5. там мы сначала создаем object чтобы узнать его id
6. потом мы переносим файлы из времянки в постоянку и указываем файлам object_id
7. получаем постоянные id файлов и сохраняем их в object

ну ладно, а в чём проблема хранить для файла юзер\группу как это делает файловая?

вот мы так и делаем )

Вышла новая версия Carbon, extension for DateTime:  2.43.0

Значит эта система знает не только о файлах, но и о хозяинах. Значит система работает только с юзерами, либо еще хранить тип объекта хозяина. Плюс надо передавать туда этот объект $fileManager->get($user, $fileId) . При этом юзер должен обладать интерфесом, который сможет отдать ID файловому менеджеру

Запрашивай доступ к ресурсу, к которому картинка привязана. Ну либо картинку к ресурсу привязывай.

не обязательно это система хранения должна все разруливать, это обязанности авторизации, которая уже аутидентифицировала юзера и вся ее обязанность в том чтобы предоставить наружу секьюрлинк в котором зашифрована связка id юзера / группы + id любой нужно сущности (например картинки или файла или объекта бизнес-логики)

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

+

Ну я про конкретный случай рассуждал :)

Добрый вечер коллеги, как я могу преобразовать UTF-8 в литеральные последовательности  (uXXXXd/)? Я хочу в таком виде хранить публикации в базе данных. Использовал json_encode но проблема только в том, что не меняет подобный текст ![]((https:\\/\\/ru.wikipedia.org\\/wiki\\/%D0%A2)

Идея в преобразовании html кода или markdown кода из редактора в markdown, а потом в литеральную последовательность. Вроде самый безопасный путь для хранения данных в базе если текст публикации пишет пользователь 🤷‍♂️ Может у вас будут лучше идеи, буду только рад ☺️

сделать base64_encode и хранить так ))))

но надо подумать о минусах )

ну это тоже круто, я могу использовать Str::words($this->content, 87, '') из Laravel, и не боятся что на выходе я получу что то типо такого ![]((https:\

а какой unicode самый малый по размеру? кстати base64 меньше оказался чем литеральная последовательность

Для чего нужно такое преобразование, в чем опасность?

Уменьшение размера хранения данных + от всяких инъекций и тому подобного, что на вывод, что на ввод

Это преобразование уменьшит размер данных? Можно пример инъекции от которой это защитит.

Про инъекцию вопрос справедливый. Возьмём пример с тегом <script>. Если бы мы работали с bb-кодами, тогда у нас не было бы предусмотрено такого bb-кода, следовательно, мы бы не обрабатывали этот тег как html-код, а просто выводили бы его как текст. Здесь логика должна быть той же самой для "не безопасных" тегов.

Кажется, что базовых тегов вполне достаточно для написания любой статьи. Заголовки, абзацы, изображения, спойлеры, выделение текста, ссылки, списки. markdown вполне хватит, зачем предоставлять пользователю html?