Там всн кейсы почти

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

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

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

Не всегда есть такие требования у бизнесов

ага, вот валидация емейла и проходит под "фанатичные проверки" ;) если хочется написать валидатор для емейла, сделай /@/ :)

Не всегда есть такие требования у бизнесов

и что? значит будут емейлы с опечатками в базе, и никак ты от этого не защитишься

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

> который основывается на моем мировозрении и опыте. контролируемая галлюцинация

Подскажите пожалуйста когда записываю доктриной в MongoDB в EmbedOne(targetDocument="...") сущность, она оказывается в базе без ID все остальные данные есть

на то она и embed one

Sergey не стоит ограничивать ввод email тебе правильно люди говорят. Хочешь помочь - помоги на фронте - подсвети оранжевым "ваш емейл выглядет странным, проверьте его". Но если ты категорически не пропустишь серверной валидацией мой валидный "its my valid custom email"@my_pizdatiy_domen.rocks то я не потрачу свои 2 бакса на твоем сервисе. Ты будешь "очень дружелюбным к пользователем" ..... и бедным

в этом же документе соседняя коллекция тоже EmbedOne(targetDocument="...") (только другой документ) записывается все полностью и ID тоже

Sergey не стоит ограничивать ввод email тебе правильно люди говорят. Хочешь помочь - помоги на фронте - подсвети оранжевым "ваш емейл выглядет странным, проверьте его". Но если ты категорически не пропустишь серверной валидацией мой валидный "its my valid custom email"@my_pizdatiy_domen.rocks то я не потрачу свои 2 бакса на твоем сервисе. Ты будешь "очень дружелюбным к пользователем" ..... и бедным

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

Сегодняшний реальный пример из жизни. Прилетел таск от человека из смежного отдела, что он не может ввсести мыло в карточку клиента. (Человек проходил тестирование на знание основ Интернета, знания урлов и должен знать как выглядят email адреса.) Работает не первый год, те с опытом. Человек прислал скрин с формой, в которой был текст ошибки Далее выдержка из переписки я - А что там написано, на скрине? он - "Введите корректный e-mail" на сколько я вижу, у меня введен корректный e-mail ввожу ic-*-*-client (за * скрыл название клиента). И как тут не плакать? Это просто боль, когда человек вводит мыло без доменной части. В данном случае, мы не валидируем адреса путем отправки на него проверочной ссылки. Подразумевается, что менеджер вносит рельный и живой адрес клиента.

На собачку проверять можно. А так, думаю, проблема в ГУИ если человек этого не понял. Напишите: "Введите email. Это строка вида example@domen.com. Обратите внимание на знак @ " и тд. На гуи ты можешь позволить себе подсказывать всю хурму. Но речь о том, что пытаясь реализовать именно валидацию емейла на сервере(валидация - либо прошел либо нет, трейтего не дано) ты будешь есть кактусы. Потому что завтра придет точно такая жалоба, что специфичный клиент не может залогинится.

В данном случае ГУИ - одна форма с 5 полями. Как ее сделать еще удобнее и понятнее - я не знаю. Да, данная подсказка не раскрывает причины по которой валидация мыла не прошла. Согласен, можно более подробно писать о ошибке. О чем уже улетел таск разрабам. Все валидации мы делаем на сервере, при сабмиете формы и стараемся показывать всю хурму с ошибками в этой же форме. При критичных для бизнеса ошибках, форму возвращаем с указанием ошибок. Если ошибки не кртитичные, то уходит таск в отдел контроля на ручную проверку. К примеру, у нас есть постер с человеческой глупостью. На нем название города Москва и варианты, как люди ошбались. Список состоит из более 30 уникальных написаний.

как получить юзера по юзернейму не лазя в репу?

нашёл в UserLoaderInterface loadUserByUsername(), но не могу найти сервис, который это реализует

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

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

тебе не надо юзать провайдер

провайдер пишется для фаервола

первый который прописан в security.yml

там их пару типов есть(chain, entity, memory шото такое)

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

сходи в репу и возьми юзера) так будет лучше

PHP-CS-Fixer или CodeSniffer?

cs fixer свежее

сходи в репу и возьми юзера) так будет лучше

ну ок

спасибо

Привет. Кто знает, как можно переопределить propertyName при сериализации JMS сериалайзером?

Привет. Кто знает, как можно переопределить propertyName при сериализации JMS сериалайзером?

https://jmsyst.com/libs/serializer/master/reference/annotations#serializedname

пробовал, не помогает почему то (

пробовал, не помогает почему то (

ну тогда почему-то никак

Это помогло https://github.com/schmittjoh/serializer/issues/334#issuecomment-190651143

Доктрина. Сохраняю пачку сущностей [ User 1-* UserPhone *-1 Phone ]. Если я добавляю новые данные в жсон внизу, то работает ок, но если пытаюсь вставить вверху или середине, то сразу же происходят разные траблы с неуникальностью полей. Как лучше всего готовить такие рилейшены ?

вверху и внизу от чего?

имею ввиду датасет с телефонами

если добавлять или удвлять новые телефоны снизу, то работает ок.

а что значит снизу в json?

Это значит сюда

ппц

порядок в json? рили?

да, порядок в жсон.

вообще-то в массиве порядок элементов сохраняется и в жсон

Доктрина. Сохраняю пачку сущностей [ User 1-* UserPhone *-1 Phone ]. Если я добавляю новые данные в жсон внизу, то работает ок, но если пытаюсь вставить вверху или середине, то сразу же происходят разные траблы с неуникальностью полей. Как лучше всего готовить такие рилейшены ?

вставля элемент по индексу у тебя сериалайзер превращает array -> object

[] -> {}

с ключами

там у тебя где-то уже провтык

Но не могу же я заставлять юзеров в жсоне еще и индексы присылать.

Я понимаю, что похоже обратная десериализация херится, но блин, как это можно порешать?

Привет всем, подскажите, а можно где-то почитать за события этого компонента?

https://symfony.com/doc/current/components/serializer.html

а у него есть события?

а у него есть события?

Не знаю, походу нет.

Поэтому и спрашиваю :)

вот все события, которые там происходят))

Но не могу же я заставлять юзеров в жсоне еще и индексы присылать.

обьясни плис задачу, вообще не понятно

кто и что тебе присылает

и зачем тебе в середину вставлять что-то?

почему просто не в конец массива?

или не давай ключам сьезжать

как только у тебя получается 0 2 3 4 5 то это уже не массив

или не давай ключам сьезжать

так там нету ключей

ERROR: S client not available

так там нету ключей

есть

как он вставляет в середину?

но пропустить 1, и иметь 0 и 2 нельзя

в пхп?

можно

та речь же о json'е

так у него на выходе не массив а обьект

и будут ключи 0 и 2

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

так у него на выходе не массив а обьект

если в json есть массив, описанный символами [] - то там будут всегда подряд ключи идти

хз, это не баг точно) надо просто разобраться в логике)

обьясни плис задачу, вообще не понятно

Задача принять и обработать данные юзера. Телефоны имеют такие рилейшены: [ User 1-* UserPhone *-1 Phone ] Дело в том, что я не хотел бы в жсоне заставлять юзера корректно отправлять индексы. Пример жсона на скрине.

так у него на выходе не массив а обьект

на выходе чего?

если в json есть массив, описанный символами [] - то там будут всегда подряд ключи идти

я знаю, он скинул один скрин когда все ок

массив

второй раз я догадывался что будет обьект

я знаю, он скинул один скрин когда все ок

а он говорит, что когда изменить порядок - фэйлится сохранение

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

я запутался) помоги тогда ему

а я хз чего у него так

я понял что у него происходит, но нету ни конфигов jms, ни маппинга доктрины, ничего

ну тогда можем пожелать удачки ?

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

от и имеет unique constraint fail

потому что номер телефона уже в прошлый раз записал)

да, номер телефона уникальное поле, и UserPhone.phone_id тоже уникальное. И при разных кейсах вставки-удаления у меня происходят фейлы с уникальностью ключа.

оооо

какие-то детали проявляются)

теперь узнали какие фейлы

А кто какой serializer может посоветовать вменяемый?

А кто какой serializer может посоветовать вменяемый?

symfony/serializer