С чего начинается работа с приложением, ботом или сайтом? Ответ прост — с регистрации пользователя в вашей системе.
В этой статье я расскажу, с какими неочевидными проблемами мы столкнулись при разработке регистрации в ботах, сайтах и приложениях. Простая на первый взгляд операция может принести существенные проблемы, если не учитывать некоторые нюансы.
Кажется, что может быть проще регистрации? Сделал стринговую переменную с ФИО, закрыл дело и пошел писать настоящий функционал. Но не тут-то было.
С вероятностью 90%, если вы сделаете так, то поначалу все будет хорошо работать, однако через некоторое время могут возникнут проблемы. Вы посмотрите в свою БД и обнаружите огромное количество мусора вместо данных, а в худшем — вы найдете свою базу в открытом доступе на всяких сомнительных форумах.
Почему это произошло?
Во-первых, никакой мотивации давать вам свои реальные данные у пользователя нет, например, в стиме 93% пользователей родилось 1 января. Объясняется такая аномалия очень просто — первый день в году стоит по умолчанию в форме выбора даты рождения и, конечно, пользователь не тратит свое время на выбор реальной даты, а просто жмет кнопку ОК и идет качать игры. И получается, что эти данные просто мусор и никакой адекватной аналитики сделать не получится. Почему это плохо, я не буду тут писать, вы все сами понимаете. Ну, а второе — просто безопасность, но об этом я расскажу чуть позже.
У нас есть проблема и нам надо ее решать. Как всегда, нужно использовать кнут и пряник для баланса. Как накормить кондитерским изделием — это задача вашего продукта, потому что для каждого случая все уникально. А вот кнут достаточно стандартный и универсальный для всех проектов.
Регулярные выражения
Очевидным решением будет проверять на адекватность данные, которые пишет пользователь. Есть всякие исключения, но, как правило, людей не зовут "X Æ A-12". Поэтому можно смело внедрять регулярные выражения и прогонять через них данные от пользователя.
Какие конкретно регулярки ставить решать только вам, для каждого проекта, повторяюсь, свое решение. А далее поговорим о типовых случаях, которые нам доставили немало головной боли.
Итак, вам в начале надо определиться о ЦА вашего продукта, поскольку каждый конкретный выбор поведет вас по уникальному пути. Продукт для какого рынка? Русского или зарубежного? Если зарубежного, то какого — китайского или европейского? Пользователи пишут на латинице, кириллице или на своей уникальной системе письма?
Да-да, это все нужно для простой и тупой, на первый взгляд, задачи как регистрация пользователя. Дело в том, что мы с вами европейцы и мыслим соответствующее, а в мире огромное количество народа с другими культурами, у которых другой тип письменного мышления, если это так можно назвать. Вариантов огромное количество, более опытные люди расскажут вам о работе со всякими редкими вещами по типу старомоногольской вертикальной письменности ᠮᠤᠩᠭᠤᠯ ( Вот тут забавно, хабр не умеет корректно отображать такой вариант письма) или арабской вязи. Поэтому определяемся, с чем мы будем работать и отсекаем все лишнее. По стандарту будем регистрировать человека на кириллице, в регулярных выражениях разрешаем только её.
Но есть одиннадцать нюансов:
-
ФИО одним полем.
Зачастую вместо трех полей делают одно, куда предлагают ввести все, что у человека есть. Кажется, в чем тут проблема? Первое слово — фамилия, второе — имя, а третье, соответственно — отчество. Но не тут было, во-первых, пользователи часто путают очередность, во-вторых, уних может быть двойное имя или отсутствовать отчество. И это либо запретит регистрацию этого пользователя, либо снизит качество данных.В идеале вы должны всегда разбивать ФИО на три разных переменных, но иногда это невозможно, потому что долгая регистрация отобьет желание использовать ваш продукт, и поэтому надо от человека в одном поле как можно быстрее получить данные. Но тогда вам надо будет отказываться от части функционала или писать монстра, который определяет где что находится и уже внутри вашей программы присваивать соответствующий класс.
2. Двойные фамилии.
Раз уже начали с этим нюансом, то продолжаем. Банальная конструкция из одного поля нормально работает, до того как вам впервые встречается человек с двойной фамилией. И тут возникает проблема — двойная фамилия по сути это одно слово, но знак не принадлежит к кириллице, из-за чего регистрация невозможна. Так что необходимо помнить об этом.
3. Двойные имена.
Аналогично с предыдущим пунктом, только теперь представьте, что бывают люди с двойными именами и с двойными фамилиями одновременно, и их полное ФИО может быть очень длинным, поэтому разучиваем максимальную длину вводимого текста с запасом.
4. ФИО из большого количества слов.
Культурный фактор, мы в России привыкли, что слов в ФИО три, хотя в некоторых странах оно может состоять из большего количества. Поэтому также учитываем это в регулярных выражениях, или делаем пометку какую часть имени и где использовать.
5. Отчество.
Из-за того, что мы все немного русскоцентричны, мы иногда забываем о других культурах, где наименования строились по совершенно другим принципам. Среднеазиатские, японские, китайские, корейские ФИО могут состоять из большего количества слов, и ни одно из них не будет отчеством.
6. Проблемы с Оглы, ибн.
А тут обратная ситуация, в тюркских языках Оглы по сути является отчеством, однако оно может писаться как через дефис, так и как отдельное слово. Учтите этот пункт, чтобы не перепутать расфасовку по переменным.
7. Несколько видов - .
‐, −, –, —. Нет, это не смайлики, это слева на право: дефис, минус, короткое тире и тире. И если у вас стоит проверка на двойное имя/фамилию, то там должен стоять знак дефиса, но пользователи могут вставить любой другой из этих символов, а регулярка просто не пропустит дальше.
8. Латиница в буквах.
Еще дополнительный аргумент вводить регулярки — это латинские буквы в русских словах. Вы не представляете сколько вам добавит боли выискивать скрытую латинскую "o" в фамилии Иванoв.
9. Буква Ё.
Если все остальные случаи являются универсальными для любых языков, то этот кейс только для русского языка. Дело в том, что regex просто не знает, что у нас в алфавите есть буква ё. Т.е. если вы напишите регулярное выражение для имени и фамилии не больше, чем 50 символов([А-Я][а-я]{1,49})\ ([А-Я][а-я]{1,49}), то такое выражение не пропустит ни мое имя (Пётр), ни содержащую эту букву фамилию. Поэтому отдельно добавляем ее в регулярки.
10. Несколько тысяч символов.
Самый тупой и самый надежный способ повесить регистрацию. Вы вводите несколько десятков тысяч символов и просто ждете. Вот тут зависит от платформы, с которой вы работаете. У нас часто был телеграмм, поэтому на нем и покажу. Он разбивает огромные сообщения на несколько частей и одновременно отсылает их на сервер. И получается, что тригер работает не на одно сообщение, а на десятки, если не сотни. Например, если у вас стоит ответное сообщение после регистрации
привет, username,
то пользователю придут несколько сотен огромных сообщений, включая это длинное имя на тысячи символов. Из-за этого есть вероятность повесить весь ваш сервис или частично сломать его.
Я лично видел, как загрузочный экран мобильного приложения Сбербанка был искорежен именем в несколько тысяч случайных символов. Так что это бич не только маленьких проектов.
11. Транскрипция (слаги).
Чуть в сторону, но думаю будет полезно. Если у вас есть перевод значений в латиницу (например, ФИО для писем за границу), то необходимо использовать единый инструмент создания слагов (человекочитаемые идентификаторы) в проекте. У нас в одном проекте были использованы 2 разных методологии создания слагов на фронте и бэке, и мы долго не понимали в чем проблема. Оказалось, что у нас идет ключевание через слаги, которые сформированы по-разному. Например, слово "транслитерация" в различных системах выглядит вот так: Transliteraciya и Transliteratsiya.
Ну, а теперь ответ на главный вопрос — почему такая обложка поста?
На скрине вы видите SQL-инъекцию. Вы наверное часто встречали это выражение, но не понимали что это по сути.
Так что же такое эта ваша SQL-иньекция? Если совсем просто, то при регистрации под видом имени пользователя вам в БД летит тупо, скорее всего, вредоносный SQL-код. Какой конкретно — неизвестно, но это дыра прямо к вам в БД.
- Как вас зовут?
- Меня зовут DROP DATABASE base1
И все, вашей базы больше нет. Да, конечно, шанс, что атакующий угадает с названием таблицы, очень мал, но никто не отменял брутфорс и промышленный шпионаж, оставлять такую дыру очень опасно. По защите от инъекций написаны сотни статей и это стандарт в ИБ. Поэтому инъекции, в подавляющем числе случаев можно сделать только тогда, когда разработчик вообще не подозревает, что так можно.
Это было финальным аргументом необходимости вводить регулярные выражения.
Основные выводы:
Меньше европоцентричности. У других культур свои правила составления имен —и это надо учитывать. Либо подгонять под свой формат, но по унифицированым сценариям.
Если можно разделить ФИО на отдельные поля — делите обязательно, это вам значительно упростит жизнь.
Если нет совсем критичных противопоказаний, то на всякий случай добавьте регулярные выражения.
Помните, что если вы напрямую кладете что-то в БД, то значит при желании, внешние специалисты могут сделать все что угодно с вашей базой.
Лучше предусмотреть самые редкие варианты написания имен, чтобы потом не бегать и искать проблему, которую зачастую сложно обнаружить.
Я не претендую на гайд, описал лишь те случаи, с которыми лично столкнулся и которые добавили мне немало головной боли. Смысл статьи — помочь новичкам обнаружить скрытые подводные камни и избавить их проекты от потенциальных проблем.
Комментарии (38)
aamonster
21.11.2021 14:14+11Надеюсь, мне не придётся регистрироваться на сделанных вами сайтах.
Проблема та же, что с валидаторами e-mail: вы чрезмерно усложняете. Примите уже, что вы не можете сами проверить корректность имени.
Peterlos Автор
21.11.2021 14:44-5Ну тут логика, что мы ничего не можем сделать, и надо сложить руки и умереть, Я против такого, если нормально посидеть и с умом решить проблему, то регистрацию можно спокойно сделать удобной и полезной для вас. Например, как это сделали многие банки.
sshikov
21.11.2021 14:47+7Например, можно вспомнить, что в SQL есть binding variables, которые полноценно предотвращают иньекции, и не париться валидацией того, структуру чего вы все равно не знаете, и узнать не сможете.
Peterlos Автор
21.11.2021 14:55-1Я писал что по SQL-инъекциям написаны сотни статей и там будет решение как залатаь эту дыру. Но статья не про это, а про то что, во-первых многие (как и я раньше) не знают что такое вообще существует и надо это держать в уме. Если можно решить по-другому — да пожалуйста. А во вторых есть проблемы и не с безопасностью, например, потенциальное залитие мусора в базу.
sshikov
21.11.2021 15:02+5>многие (как и я раньше) не знают что такое вообще
Не, на самом деле тут я просто уточнил, что для проблемы иньекций есть решения и получше валидации, потому что валидировать то, что вы не знаете точно, все равно не выйдет никак. Скажем, почту валидировать все равно нет смысла — нужно послать письмо, и ее подтвердить, получив ответ. Т.е. это другое действие обычно.
>потенциальное залитие мусора в базу
Согласен, это другая проблема. Но вам не кажется, что наложив ограничения на имя, вы просто получите вместо мусора неструктурированного — мусор по вашим правилам? Ну т.е. будет там везде Иванов Иван Иванович, 01-01-1970 года рождения, номер телефона +7 495-000-00-00, и что вам это дало?Peterlos Автор
21.11.2021 17:04-11) Это другой бизнес-процесс. Нужен ли тут он, решает бизнес-архитектор. Я лишь пишу, если вы решили сделать валидацию написаного текста, то учтите эти аспекты.
2) И да, и нет. Мусора будет меньше, потому что надо запариваться чтото придумывать, проще реальные данные дать. И да, будет структурированный мусор, но тут уже нужно делать по-другому, дать мотивацию самому писать реальные данные.sshikov
21.11.2021 17:16+3>проще реальные данные дать
Ну, бывает конечно и так. Но мне кажется далеко не всегда.
>надо запариваться чтото придумывать
Да вовсе не надо. Вот же я придумал — даже не напрягаясь. Вы правда верите, что человек глупее регулярного выражения? :)
Во всяком случае, когда мне приходится такое заполнять, я либо просто уйду в другое место, если есть выбор, либо заполню таки мусором, но формально удовлетворю валидацию. Потому что если у меня нет интереса (мне скажем не нужна доставка, для чего я бы указал реальный адрес вообще без вопросов), то от добавления валидации этого интереса не станет больше ни на грош.
>дать мотивацию самому писать реальные данные.
Так я а о чем? Если уж вам сразу хочется реальные — лучше этим и заморачиваться.Peterlos Автор
21.11.2021 17:29ну мы стремимся улучшить качество данных, понятно что 100 процентов никогда не будет.
Так я за это и топлю. И пишу. Но это никак не противорчит тому, что мы должны дыру в бд закрыть и не позволять заливать, например, 100к символов в нее.
В некоторых сервисах, если вы уйдете с регистрации лучше, чем вы оставите свои фейковые данные. Все зависит от конкретных кейсов.
aamonster
21.11.2021 14:59+5Ну а что, не можешь сделать ничего – хотя бы сломай UX? Так себе решение. По мне, не можешь сделать ничего – не делай ничего.
Проверить имя-фамилию юзера вы сможете, когда он вам паспорт покажет. Ну или с госуслуг подтянуть, если есть возможность.
Dekmabot
21.11.2021 14:18+4Это лишь холмик в горах. При создании авторизации, кроме разделения фио на слова, есть вопросы уникальности учёток, шифрования и хранения паролей и соли, логин или email, восстановление или сброс пароля, подтверждение email, токены, роли и права, параллельные сессии, вход по openid/oauth, локализация и так далее.
Поэтому если цель "закрыл дело и пошел писать настоящий функционал", на старте проще использовать внешние iam-сервисы.
Peterlos Автор
21.11.2021 14:46Конечно, я согласен что внешие использовать проще. Но, в некоторых случаях это невозможно, например, если у вас регистрация через мессенджеры или эти данные конфедициальны, так что передавать третьим лицам не вариант.
tempick
21.11.2021 15:53Да, именно это я и ожидал вообще увидеть в статье. Или хоть что-нибудь из этого
laatoo
21.11.2021 14:30+13Как зарегистрировать пользователя и не сломать себе голову: не мешайте ему вводить такое имя, какое он хочет, но будьте готовы что там может оказаться что угодно.
ВСЁ
Если на имя будут оформляться документы/доставки итп — пользователь больше вас заинтересован в том, чтобы там не было эмодзи
Peterlos Автор
21.11.2021 14:47-5А я про это писал, что есть метод пряника, если человек сам заинтересован дать вам хорошие данные, то и кнут не нужен. Но, к сожалению, так происходит не всегда.
laatoo
21.11.2021 14:49+9Так если пользователь не заинтересован в том чтобы сказать вам свое имя — нечего спрашивать
Peterlos Автор
21.11.2021 16:56Статья лишь про то, что если нужно сделать такую регистрацию, вот как сделать качественно. Если считаете что не нужны реальные данные для бизнес-процесса, то и регистрация не нужна.
tempick
21.11.2021 19:52Справедливости ради, ваши решения никак не мешают вбивать не «реальные данные». Вообще, по моей практике (у меня её не так много, но всё же) проще делать стандартную регистрацию по email(/ник/телефон)+пароль, а остальные поля уже в профиле пользователь по желанию может вбить.
Если речь про ботов (чисто субъективно — регистрация через ботов — это мне, как пользователю — тот ещё гемор), то там у каждого пользователя в том же телеграме можно получить и имя пользователя в телеграм, и его id.
Если вы переживаете, что в его профиле указано не настоящее имя, то можно, например, опционально дать возможность указать другое имя, если это так важно. Хотя чаще (опять же, по моей практике) фамилия и имя обычно указываются для удобства самого пользователя и не несут большой смысловой нагрузки для бизнеса (кроме случаев условных доставок, где надо получить посылку по паспорту или гос. контор или букмекерских контор и т.д.)
Chronicler
21.11.2021 15:27+9Во-первых, никакой мотивации давать вам свои реальные данные у пользователя нет,
...
У нас есть проблема и нам надо ее решать. Как всегда, нужно использовать кнут и пряник для баланса.А не многовато ли вы на себя берете? Если реальной нужды указывать настоящие данные нет, в чем вы признались, то зачем усложнять пользователю жизнь выбивая их? Уж не приторговываете ли вы данными? В общем, посыл отвратителен, отношение неуважительное, ставлю статье минус. Надо больше любить людей!
Peterlos Автор
21.11.2021 16:54-4Еще шаг и я Гитлер, смотрю)
Зачем вам давать свои реальные данные, когда вы берете кредит? Или когда регистрируетесь в каршеринге? Или когда арендуете другие вещи?Есть ситуации, когда бизнес пытаються обмануть и его издержки переводят на ваши плечи.
Статья о том, если вы хотите сделать регистрацию, то сделайте ее качественной, если не хотите, то можете не делать, никто не заставляет.
vikarti
21.11.2021 16:00+3ФИО тремя полями? 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 логин), есть платежные реквизиты где имя и адрес вводятся отдельно и к имени единственное требование "как на карте" ).
laatoo
22.11.2021 08:48+1Моё любимое — когда от тебя в обязательном порядке требуют полный набор данных, начиная с ФИО, заканчивая рабочим телефоном и почтовым индексом, для получения цирового товара, который тебе пришлют по электронной почте/дадут ссылку на скачивание в личном кабинете.
Обычно это сопровождается безумными регулярками, которые не пропускают домены 3 уровня в email'е, select'ами с выбором страны и региона, экзотическими требованиями к паролю итд итп. Уверен, в подобной базе данных примерно все поля заполнены всеми возможными whocares'ами и fuckoff'ами, и единственное поле, которое заполнено реальными данными — email (и тот, скорее всего, одноразовый)
Ну хотя нет, не единственное. Ещё почтовый индекс, вот он совершенно точно соответствует указанному региону, ведь без него форма не отправится!
P.S: за ссылку на w3 спасибо, интересно
vikarti
22.11.2021 09:33+2Мне вот еще вспоминается история с русским переводом Харрис и Харрис и его бесплатным распространением. Только заполните анкету.
Там инициатор проекта на Хабре прямо писал что начальство убедил именно что у них будет база по анкетам тех студентов кому это интересно и кто учится на соответствующих специальностях и кому потом можно будет попробовать лицензии продать на IP-ядра (что имеет смысл, если человеку реально нужен такой учебник — он вероятно будет работать в той области где лицензии эти имеет смысл покупать, если человеку просто интересно — ну хуже то не будет).Но вот только процедура заполнения анкеты была ну очень удобной и прямо в темах на хабре ссылки на cloud.mail.ru, amazon s3 и dropbox
(https://habr.com/ru/post/259505/ https://habr.com/ru/post/306982/ )
v1a0
21.11.2021 16:50А что делать с символьным мусором? По типу:
????꙰꙰꙰꙰꙰꙰⃟꙰⃟꙰⃟꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰⃟꙰⃟꙰⃟꙰꙰꙰Логично его просто как-то фильтровать или заменять на что-то типа "???", особенно если сохраняете в БД ники пользователей. Телеграм все ещё позволяет напихать в них такого мусора, что может заслонять сообщения других пользователей в группах.
ФАКТ!
Если вставите текст выше в окно комментария, даже хабр поплывет!
Peterlos Автор
21.11.2021 17:46-2На меня тут напали, что такая регистрация вообще не нужна.
Решать нужна ли регистрация со свободными полями или жестко зарегулирована только вам, я лишь хотел рассказать, на что нужно смотреть, если все-такие решили писать ограничения.
Мы писали бота, который автоматически формирует документы для работы. Он был предбанником CRM, люди не привыкли к такой системе и писали, например, ники или уменьшительно-ласкательные имена. И да, мы писали плашки как надо писать. Но все равно приходилось фиксить ошибки в уже сформированных доках.
И после введения всех перечисленных правил, пользователи начали писать все корректно и документы начали формироваться нормально.
Если вы считаете, что можно в поля писать все что угодно, пожалуйста, это просто другой подход, не лучше и не хуже.
Areso
21.11.2021 19:03+2Есть "счастливчики" кого прямо в паспорт записали по уменьшительно-ласкательному имени (когда совпали звезды, и в роддоме был пьяный отец и пьяный же писарь). Например, Танька Иванова (ну, случается, чё) или Танюшка Стрелкова. Окей, вот приходит такой человек, пытается зарегаться в сервисе, а ему строгий бот отвечает: "нельзя так писать, пишите как в паспорте!". И дальше что делать? Искать поддержку, которая, внезапно, почти такой же бот в том же телеграме и начнёт с того же требования?)
Да, в большинстве случаев вы повысите качество данных, но в каком-то проценте случаев вы просто убьёте не совсем стандартных пользователей.
Matshishkapeu
21.11.2021 18:06+8У таких навязчивых люителей аналитики из разряда "пройдите три экрана регистрации чтобы скачать файл" большая доля аналитиики выглядит так
пользователь: Fuck Off
дата рождения: 01.01.1900
e-mail ( действительный мы отправим запрос на подтверждение !!!111) : fuck.off@mailinator.com
TITnet
21.11.2021 23:09+1Вы описали только работу с именем.
Её можно сильно упростить.
Два поля. Имя для документов и Имя для обращения к пользователю.
Имя для документов: Сергей Сергеевич Сергеев (как в паспорте)
Имя для обращения в письмах: Серёжа (да, я хочу, чтобы ко мне неформально обращались Серёжа.
Не нужно пытаться делить имя на составные части (ФИО).
Areso
22.11.2021 18:59+1Кстати, из свежего негативного опыта - Яндекс.Маркет требует ФИО кириллицей. Как быть тем пользователям, у кого документы, кхм, на латинице?)
tempick
Всё так хорошо начиналось и неожиданно закончилось) Ожидал почитать не только про ввод имени но и другие интересные нюансы. Но все равно спасибо
Peterlos Автор
У меня были заготовки и для дат, но подумал что статья выйдет слишком огромной, поэтому не стал все в кучу смешивать.
tempick
скорее всего, просто заголовок вводит в заблуждение. Ввод имени и даты — это, всё же, про валидацию данных, а не про регистрацию.
michael_v89
Не надо следовать советам из этой статьи. Всю статью можно заменить на один совет — в SQL-запросах используйте именованные параметры. Тогда никакие регулярки для проверки будут не нужны, и не надо будет учитывать 11 нюансов.