тогда можно свой ресолвер заделать, который будет кидать исключение

рантайм-чекер типов чутка поможет тут не забыть про #[Security] над методом

тогда можно свой ресолвер заделать, который будет кидать исключение

у меня есть свой ресолвер, да. но до него управление не доходит. сначала надо отресолвить аргументы, потом уже секурити чекать, по крайней мере сейчас так. и я не до конца уверен, что можно (и нужно) менять местами эти лиснеры (секурити и controller.argument_value_resolver

к тому же, понять в аргументс ресолвере, нужен ли конкретно этому методу юзер, не так-то и просто

к тому же, понять в аргументс ресолвере, нужен ли конкретно этому методу юзер, не так-то и просто

почему? через рефлексию можно посмотреть, нуллабл или нет

всё, понял твою идею. звучит жестковато, если честно

даже ресолвер для этого не нужен, просто какой-то лиснер, который раньше controller.arguments сработает и им проверить, есть ли сейчас авторизованный юзер и можно ли этот метод вызывать без юзера

я не до конца уверен, что до того как сработают все секурити-лиснеры, можно будет понять "авторизован ли щас кто-то"

скорее, быть может, надо покопаться в ту сторону, что юзер всегда может быть (то есть разрешена анонимная аутетентификация), но у него не будет ролей

грубо говоря, чтобы getUser() и прочее всегда возвращали инстанс UserInterface, пусть и без ролей

грубо говоря, чтобы getUser() и прочее всегда возвращали инстанс UserInterface, пусть и без ролей

А что если сделать фактори сервис, с названием класса User, который возвращает текущего пользователя, а иначе кидает ексепшн? =)

тогда секурити сломается

А что если сделать фактори сервис, с названием класса User, который возвращает текущего пользователя, а иначе кидает ексепшн? =)

я вчера такое уже предлагал)

она, если видит что есть юзер, считает что ты залогинен

поэтому, если мы каким либо образом подсунем в контейнер сервис юзера, все сломается

но идея все равно хорошая, доберусь до компа - потыкаю. возможно и правда сработает

поэтому, если мы каким либо образом подсунем в контейнер сервис юзера, все сломается

Мы в фактори сервис подсунем token storage сервис, оттуда получим текущего пользователя

Мы в фактори сервис подсунем token storage сервис, оттуда получим текущего пользователя

кстати, doctrine param converter может помешать

их отключить пришлось

и руками проставлять #[Entity]/#[ParamConverter]

Мы в фактори сервис подсунем token storage сервис, оттуда получим текущего пользователя

не работает

кстати, doctrine param converter может помешать

Из-за этого?

не, пытаюсь понять почему

почему-то кто-то куда-то редиректит и это зацикливается в ERR_TOO_MANY_REDIRECTS

Попробуйте не кидать access denied

а что кидать?

Пока ничего, чтобы проверить причину. Если бесконечный редирект прекратится, значит из-за него

Или просто Exception

да, мой эксепшн кидается, всё ок

https://cdn.weblab.pro/675dd.png

Это класс зареган как фактори?

ага

App\Entity\User: factory: ['@App\Service\UserProvider', getUser]

интересно, можно ли фактори-сервису нулл возвращать

Нужно попробовать сделать фактори lazy

мысль, да

похоже что получилось

а кстати даже без лейзи

public function getUser(): ?User { return $this->tokenStorage->getToken()?->getUser(); }

вот такого фабричного метода хватило

public function getUser(): ?User { return $this->tokenStorage->getToken()?->getUser(); }

Тогда нет смысла... Он nullable

ну вот говорю, чтобы DI обмануть этого хватило и всё работает

Нужно сделать lazy, и чтобы кидало access denied exception

Нужно сделать lazy, и чтобы кидало access denied exception

Вы же изначально хотели так

И ещё чтобы всегда возвращал user, а не нулл

у меня есть экшны, которые могут быть доступны анонимнам

поэтому там тайпхинт ?User

но повторюсь, мне нужно было обмануть DI, сказав, что сервис User есть, это с вашей помощью удалось сделать, спасибо. а вот подстановкой реального юзера в этот экшн уже секурити занимается

поэтому всё завелось именно вот в таком виде

👍

Подскажите, а это нормально, когда класс сущности превращается в портянку из мета-данных (аннотации или атрибуты) ? В результате у одного свойства может быть 10-15 строк мета информации, связанные с доктриной, валидацией, социализацией и прочими ?

не очень, потому что бизнессущность торчит наружу

так на практике обычно и делают? или лучше в конфигурации выносить?

не очень, потому что бизнессущность торчит наружу

а как иначе делают?

то, как делают обычно не имеет отношения к тому, как следует делать

тогда, как следует?)

отдельные дто на чтение, которые сериализуются как есть

отдельные дто команд на обновления, на которых и вешают валидацию

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

пока есть какие-то не особо оформившиеся идеи в трейт вынести

или что-то придумать с наследованием

с трейтами другие проблемы бывают. с которыми уде столкнулся. например при использовании трейтов TimestampableEntity при необходимости добавить какую-то мета-информацию к ним для определенной сущности, приходится вытаскивать эти поля из трейта в сущность, чтобы переопределять

типа чтобы везде в бизнес-логике фигурировала сущность А, наследованная от А1 (в ней вся метадата доктрины-сериалайзера-валидации итд), а для админки есть третья сущность Б с сеттерами-геттерами на каждое поле

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

Трейты не очень подходят

Будут проблемы с ними

Вообще странная проблема у тебя

Не нравится портянка, гу раскидай её везде

Будешь потом лазить по коду находить где что

Мне наоборот нравится когда все в одном месте. Видомо дело вкуса

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

потом во время всей остальной работы с кодом и сущностями, она тебе не нужна, чем дальше она будет - тем лучше

Пиши их в ямле

гуд пойнт

Правильно понимаю, что предлагаете сущности разбивать на слои? Типа первый слой сущности - это слой описывающие ее с мета-данными доктрины. Второй слой - сущность с валидаторами, стерилизаторами и т.д. А третий - с бизнесовыми методами?

во время работы с сущностью вообще интерфейс нужен, если честно, а не реализация. тогда в реализации можно любую помойку держать, заглядывать туда ты особо не будешь, тк везде в коде будет виден интерфейс этой сущности. будет чуть больше писанины, но зато clean code

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

почему один раз? а при миграциях?

Пришел запрос, он мапится в сущность ДТО, на которую навешены валидации Потом мапиш это в сущность доктрины, на которой только доктрин аннотации

почему один раз? а при миграциях?

ну это редко по сравнению с повседневным контактом с кодом. поля ты меняешь сильно реже, чем работаешь с методами этой сущности

Лично я так не делаю ибо не люблю лишние сущности создавать