Там фильтр есть Fetch/XHR - надо на него нажать, сделать запрос на авторизацию и его изучить

Смотрел

При авторизации он все возвращает, устанавливает phpsesid

А когда нет - пишет в теле error invalid credentials

Такая связка работает нормально. В services.yml json_login настроил?

Коллеги, есть проблема, пока не нагуглил ни решения, ни понимания.
Есть форма с профилем пользователя. Простая, буквально стандартная.
Есть там имя пользователя. И если я меняю имя пользователя на существующее чужое, то симфони (5ка, если что) меня разлогинивает (показав ошибку перед этим, что поле уже существует, но второй раз страница уже не откроется).
Я так понимаю, что надо в контроллере вместо handleRequest (который пробует сохранить сущность, как я понял) сначала проверить как-то на предмет адского ужаса результаты. Есть validatorInterface, вроде для этого создан, но как для него достать объект из формы - пока не понял.
Или просто проверить отдельно юзернейм, чтобы не дублировался, и если с ним все ок, то отправлять форму уже штатными средствами?

Тебе надо идти от обратного. Сначала решить что и как твоя форма должна делать, а потом смотреть что она делает

А конкретный фреймворк уже такое

А это просто профиль пользователя. То есть она должна дать юзеру возможность поменять любую доступную информацию о себе, включая имя, если оно не чужое.
Вопрос, что при вызове handleRequest форма выдает ошибку (как и должна), но при этом где-то внутри пользователя разлогинивает. Почему - я пока не понимаю.

Это точно просто форма профиля, а не авторизационная никакая?

вообще ни разу с авторизацией не связана, хотя пароль там можно поменять.
Эту проблему для 4ки обсуждают в интернетах, там вся проблема в том, что делается персист на пользователя, который не валиден, в результате получается, что форма разлогинивает человека. Но в 5ке все делается внутри handleRequest, я ручками persist не вызываю даже.

Кто-нибудь сталкивался с тем, что доктрина при команде doctrine:migration:diff генерирует дубликаты, т.е. для некоторых полей прописывает заново тип поля и дропает значение по-умолчанию ? Хотя эти поля никак не менялись. Бд postgres 13.3, symfony 5.3, крутится все в докере. Пробовал сносить все миграции, сгенерировать заново, накатить ее и вызвать дифф - опять генерируется миграция с указанием типа и дропом значения по-умолчанию. Если ее тоже накатить и опять вызвать дифф, сгенерируется точно такая же миграция. В гугле натыкался только с проблемами в maria db и что там полную версию бд нужно было прописывать - это тоже не помогло. Пробовал накатывать старую версию постгреса - тоже самое. Заранее спасибо.

Генерирует такое. Если ее накатывать, то после диффа сгенерируется точно такая же

Это проблема подхода а не 4ки.
Валидировать стоит запрос а не сущность (которую к тому же ещё и меняют зачем то).

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

Правда, нахрена вам тогда форма, это уже отдельный вопрос, но дело вкуса.

Проблему решил. Возникали дубли из-за кастомных типов, в которых отсутствовал метод requiresSQLCommentHint, возвращающий true. Видимо упустил этот момент в доке.

Во, Андрей, что-то такое я и хотел услышать. Про DTO доселе почти не слышал, ушел гуглить. Благодарю!

может у кого-нибудь есть готовая сборка docker для symfony 5, nginx, postgres?

1 - при обновлении сущности не требуется parsist, достаточно flush
2 - handleRequest никакого persist или flush не делает, просто валидация форнт-данные согласно типу полей или других указанных требованиях валидатора
3 - форма никак не валидирует отправленные данные с данными в бд - это твоя задача непосредственно перед тем как сохранить изменения вызвав flush, т.е. делается отдельный запрос, и в случае конфликта выводишь соответствующее сообщение
4 - разлогинивать может если применять сущность User наследованным от интерфейса UserInterface, в нем есть магия описанная в методе isEqualTo, в котором при изменении неких значений (мыла, пароля, и пр.) - система обязана разлогинивать такого пользоватаеля. То что разлогинивает пользователя пусть даже с ошибкой думаю все же связано с самим объектом, в котором произошли изменения и сессия тем самым гасится