Как правильно реализовать вариантивность регистрации по email или номеру телефона?
Допустим, на данный момент есть таблица user с набором полей:
- id[int, 11, primary, unique] - email[varchar, 255, key, unique]
- login[varchar, 255, key, unique] - password_hash[varchar, 255]
В качестве данных для авторизации используется пара login, password_hash.
Задача:
1. Убрать поле login из таблицы.
2. Ввести номер телефона. Дать возможность пользователю при регистрации использовать email ИЛИ номер телефона. То есть, только одно на выбор: либо email, либо номер телефона.
Вопрос в том, как это лучше реализовать задачу №2.
Я вижу это так: сделать поле email возможностью быть null, ввести поле phone_number с unique-индексом также с возможностью быть null. При регистрации в зависимости от выбора в одно из полей пишутся данные, другое остается со значением null.
Является ли подобный подход верным, и могут ли быть серьезные подводные камни?
Была альтернативная мысль в создании одного лишь поля идентификатора, куда пишется email/номер телефона. По-сути, цель поля одна - идентификация, а в back-end в некоторых местах(пример: восстановление пароля) можно создать метод для определения типа данных и уже этим манпулировать. Правда, при таком подходе если нужна выборка номера телефонов/email будут проблемы. Но можно создать отдельное поле, которое будет сообщать что хранится в идентификаторе - email или номер телефона.
Ну да. Как вы описали - так и делается. Поля в БД должно быть два (а может быть и одно, если вы хотите расширяемую в будущем систему - можно создать одно поле 'login_type', и в связанной таблице уже распределять логины по типу), а поле на фронтенде может быть одно.
Дальше 2 варианта:
1) Определять что за тип данных отправляет пользователь с помощью JS и в самом JS уже присваивать нужный ключ и отправлять запрос. Это дешевле и проще.
2) На сервере перед передачей запроса непосредственно в вашу логику его нужно отфильтровать и присвоить определенный ключ - либо email, либо phone_number.
Соответственно еще нужно валидировать запрос, т.е. не допускать отсутствие или не вхождение введенных данных в формат email или номера телефона.
unique index нужно делать на пару полей (phone, email).
в будущем возможно захочется чтобы один юзер мог логинится и по мылу и по емеилу. либо использовать второе на случай восстановления.
если юзер не будет долго пользоваться симкой, то номер оператор отберет навсегда, и залогиниться уже никак не получится, если нет емеила.
