Pull to refresh

Comments 38

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

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

скорее всего, просто заголовок вводит в заблуждение. Ввод имени и даты — это, всё же, про валидацию данных, а не про регистрацию.

Не надо следовать советам из этой статьи. Всю статью можно заменить на один совет — в SQL-запросах используйте именованные параметры. Тогда никакие регулярки для проверки будут не нужны, и не надо будет учитывать 11 нюансов.

Надеюсь, мне не придётся регистрироваться на сделанных вами сайтах.

Проблема та же, что с валидаторами e-mail: вы чрезмерно усложняете. Примите уже, что вы не можете сами проверить корректность имени.

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

Например, можно вспомнить, что в SQL есть binding variables, которые полноценно предотвращают иньекции, и не париться валидацией того, структуру чего вы все равно не знаете, и узнать не сможете.

Я писал что по SQL-инъекциям написаны сотни статей и там будет решение как залатаь эту дыру. Но статья не про это, а про то что, во-первых многие (как и я раньше) не знают что такое вообще существует и надо это держать в уме. Если можно решить по-другому — да пожалуйста. А во вторых есть проблемы и не с безопасностью, например, потенциальное залитие мусора в базу.

>многие (как и я раньше) не знают что такое вообще
Не, на самом деле тут я просто уточнил, что для проблемы иньекций есть решения и получше валидации, потому что валидировать то, что вы не знаете точно, все равно не выйдет никак. Скажем, почту валидировать все равно нет смысла — нужно послать письмо, и ее подтвердить, получив ответ. Т.е. это другое действие обычно.

>потенциальное залитие мусора в базу
Согласен, это другая проблема. Но вам не кажется, что наложив ограничения на имя, вы просто получите вместо мусора неструктурированного — мусор по вашим правилам? Ну т.е. будет там везде Иванов Иван Иванович, 01-01-1970 года рождения, номер телефона +7 495-000-00-00, и что вам это дало?

1) Это другой бизнес-процесс. Нужен ли тут он, решает бизнес-архитектор. Я лишь пишу, если вы решили сделать валидацию написаного текста, то учтите эти аспекты.

2) И да, и нет. Мусора будет меньше, потому что надо запариваться чтото придумывать, проще реальные данные дать. И да, будет структурированный мусор, но тут уже нужно делать по-другому, дать мотивацию самому писать реальные данные.

>проще реальные данные дать
Ну, бывает конечно и так. Но мне кажется далеко не всегда.

>надо запариваться чтото придумывать
Да вовсе не надо. Вот же я придумал — даже не напрягаясь. Вы правда верите, что человек глупее регулярного выражения? :)

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

>дать мотивацию самому писать реальные данные.
Так я а о чем? Если уж вам сразу хочется реальные — лучше этим и заморачиваться.

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

Так я за это и топлю. И пишу. Но это никак не противорчит тому, что мы должны дыру в бд закрыть и не позволять заливать, например, 100к символов в нее.

В некоторых сервисах, если вы уйдете с регистрации лучше, чем вы оставите свои фейковые данные. Все зависит от конкретных кейсов.

Ну а что, не можешь сделать ничего – хотя бы сломай UX? Так себе решение. По мне, не можешь сделать ничего – не делай ничего.

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

Это лишь холмик в горах. При создании авторизации, кроме разделения фио на слова, есть вопросы уникальности учёток, шифрования и хранения паролей и соли, логин или email, восстановление или сброс пароля, подтверждение email, токены, роли и права, параллельные сессии, вход по openid/oauth, локализация и так далее.

Поэтому если цель "закрыл дело и пошел писать настоящий функционал", на старте проще использовать внешние iam-сервисы.

Конечно, я согласен что внешие использовать проще. Но, в некоторых случаях это невозможно, например, если у вас регистрация через мессенджеры или эти данные конфедициальны, так что передавать третьим лицам не вариант.

Да, именно это я и ожидал вообще увидеть в статье. Или хоть что-нибудь из этого

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


ВСЁ


Если на имя будут оформляться документы/доставки итп — пользователь больше вас заинтересован в том, чтобы там не было эмодзи

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

Так если пользователь не заинтересован в том чтобы сказать вам свое имя — нечего спрашивать

Статья лишь про то, что если нужно сделать такую регистрацию, вот как сделать качественно. Если считаете что не нужны реальные данные для бизнес-процесса, то и регистрация не нужна.

Справедливости ради, ваши решения никак не мешают вбивать не «реальные данные». Вообще, по моей практике (у меня её не так много, но всё же) проще делать стандартную регистрацию по email(/ник/телефон)+пароль, а остальные поля уже в профиле пользователь по желанию может вбить.
Если речь про ботов (чисто субъективно — регистрация через ботов — это мне, как пользователю — тот ещё гемор), то там у каждого пользователя в том же телеграме можно получить и имя пользователя в телеграм, и его id.
Если вы переживаете, что в его профиле указано не настоящее имя, то можно, например, опционально дать возможность указать другое имя, если это так важно. Хотя чаще (опять же, по моей практике) фамилия и имя обычно указываются для удобства самого пользователя и не несут большой смысловой нагрузки для бизнеса (кроме случаев условных доставок, где надо получить посылку по паспорту или гос. контор или букмекерских контор и т.д.)

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

А не многовато ли вы на себя берете? Если реальной нужды указывать настоящие данные нет, в чем вы признались, то зачем усложнять пользователю жизнь выбивая их? Уж не приторговываете ли вы данными? В общем, посыл отвратителен, отношение неуважительное, ставлю статье минус. Надо больше любить людей!

Еще шаг и я Гитлер, смотрю)

Зачем вам давать свои реальные данные, когда вы берете кредит? Или когда регистрируетесь в каршеринге? Или когда арендуете другие вещи?

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

Статья о том, если вы хотите сделать регистрацию, то сделайте ее качественной, если не хотите, то можете не делать, никто не заставляет.

Реально полезным и новым знанием для меня оказалась буква ё в регэкспах.

ФИО тремя полями? https://shinesolutions.com/2018/01/08/falsehoods-programmers-believe-about-names-with-examples/ почитайте
Или русский перевод более старой версии https://habr.com/ru/post/146901/
ну и https://www.w3.org/International/questions/qa-personal-names


Уж проще — одно имя, и не ограничивать вообще никак.


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


Куча сайтов где что то где то покупать — есть данные об имени одной строкой (иногда вообще полученной через Facebook/Google логин), есть платежные реквизиты где имя и адрес вводятся отдельно и к имени единственное требование "как на карте" ).

Моё любимое — когда от тебя в обязательном порядке требуют полный набор данных, начиная с ФИО, заканчивая рабочим телефоном и почтовым индексом, для получения цирового товара, который тебе пришлют по электронной почте/дадут ссылку на скачивание в личном кабинете.


Обычно это сопровождается безумными регулярками, которые не пропускают домены 3 уровня в email'е, select'ами с выбором страны и региона, экзотическими требованиями к паролю итд итп. Уверен, в подобной базе данных примерно все поля заполнены всеми возможными whocares'ами и fuckoff'ами, и единственное поле, которое заполнено реальными данными — email (и тот, скорее всего, одноразовый)


Ну хотя нет, не единственное. Ещё почтовый индекс, вот он совершенно точно соответствует указанному региону, ведь без него форма не отправится!


P.S: за ссылку на w3 спасибо, интересно

Мне вот еще вспоминается история с русским переводом Харрис и Харрис и его бесплатным распространением. Только заполните анкету.
Там инициатор проекта на Хабре прямо писал что начальство убедил именно что у них будет база по анкетам тех студентов кому это интересно и кто учится на соответствующих специальностях и кому потом можно будет попробовать лицензии продать на IP-ядра (что имеет смысл, если человеку реально нужен такой учебник — он вероятно будет работать в той области где лицензии эти имеет смысл покупать, если человеку просто интересно — ну хуже то не будет).


Но вот только процедура заполнения анкеты была ну очень удобной и прямо в темах на хабре ссылки на cloud.mail.ru, amazon s3 и dropbox
(https://habr.com/ru/post/259505/ https://habr.com/ru/post/306982/ )

image
Ну и как же без классической пикчи ))

А что делать с символьным мусором? По типу:

?꙰꙰꙰꙰꙰꙰⃟꙰⃟꙰⃟꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰꙰

Логично его просто как-то фильтровать или заменять на что-то типа "???", особенно если сохраняете в БД ники пользователей. Телеграм все ещё позволяет напихать в них такого мусора, что может заслонять сообщения других пользователей в группах.

ФАКТ!
Если вставите текст выше в окно комментария, даже хабр поплывет!

Это контриться ограничением на длинну поля. И прочими регулярками.

На меня тут напали, что такая регистрация вообще не нужна.

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

Мы писали бота, который автоматически формирует документы для работы. Он был предбанником CRM, люди не привыкли к такой системе и писали, например, ники или уменьшительно-ласкательные имена. И да, мы писали плашки как надо писать. Но все равно приходилось фиксить ошибки в уже сформированных доках.

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

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

Есть "счастливчики" кого прямо в паспорт записали по уменьшительно-ласкательному имени (когда совпали звезды, и в роддоме был пьяный отец и пьяный же писарь). Например, Танька Иванова (ну, случается, чё) или Танюшка Стрелкова. Окей, вот приходит такой человек, пытается зарегаться в сервисе, а ему строгий бот отвечает: "нельзя так писать, пишите как в паспорте!". И дальше что делать? Искать поддержку, которая, внезапно, почти такой же бот в том же телеграме и начнёт с того же требования?)

Да, в большинстве случаев вы повысите качество данных, но в каком-то проценте случаев вы просто убьёте не совсем стандартных пользователей.

Мы смотрим сформированные доки и паспорт, если совпадает, то нам без разницы как его зовут. Мы не используем словари имен и тп.

У таких навязчивых люителей аналитики из разряда "пройдите три экрана регистрации чтобы скачать файл" большая доля аналитиики выглядит так

пользователь: Fuck Off

дата рождения: 01.01.1900

e-mail ( действительный мы отправим запрос на подтверждение !!!111) : fuck.off@mailinator.com

Интересно теперь, как у вас организована работа с паролями.

Вы описали только работу с именем.

Её можно сильно упростить.

Два поля. Имя для документов и Имя для обращения к пользователю.

Имя для документов: Сергей Сергеевич Сергеев (как в паспорте)

Имя для обращения в письмах: Серёжа (да, я хочу, чтобы ко мне неформально обращались Серёжа.

Не нужно пытаться делить имя на составные части (ФИО).

Кстати, из свежего негативного опыта - Яндекс.Маркет требует ФИО кириллицей. Как быть тем пользователям, у кого документы, кхм, на латинице?)

Sign up to leave a comment.

Articles