объяснение имени
Мультиаккаунт здесь отличается от системного уровня.Система мультиаккаунтов, о которой мы говорим, означает, что в наших интернет-приложениях наше приложение будет использовать несколько сторонних учетных записей для входа в систему, а обычно используемое приложение (NetEase Cloud Music ) необходимо использовать метод входа в систему. В том числе: NetEase, WeChat, QQ
содержание
Благодаря этой статье, Что можно узнать: подробности технического решения ниже многопользовательского, а также соответствующий дизайн таблицы и дизайн процесса. Нет: Как и в других статьях, здесь я не буду приводить конкретные детали реализации кода, план правильный, и код будет не так уж и плох. Логин Netease.png
Эволюция архитектуры
Ранняя стадия бизнеса
Это сводится к начальному этапу предпринимательства, потому что количество пользователей в настоящее время относительно невелико, а другие упомянутые выше сторонние учетные системы даже не подключены, но самодельная система может быть удовлетворена.
Логин ПарольРегистрацияЛогин
Этот метод будет использоваться во многих первоначальных конструкциях веб-сайтов.Сначала зарегистрируйтесь, а затем войдите в систему.Эту тень можно найти в старых cms.
блок-схема:
Описание потока:
- Внешняя часть отправляет имя пользователя и пароль на сервер, а сервер выполняет стандартную оценку, чтобы определить, удовлетворяет ли длина имени пользователя и пароля и повторяется ли имя пользователя.Во время передачи оно перехватывается. Рекомендуется зашифровать его перед загрузкой.Наш пароль для передачи будет по умолчанию зашифрован md5, а затем записан в базу данных для другого уровня шифрования.
- После прохождения проверки имя пользователя и пароль будут записаны в базу данных, и будут выполнены следующие операции, такие как распределение баллов, которые здесь не будут раскрываться.
- Теперь войдите в систему, интерфейс отправляет имя пользователя и пароль на сервер, и сервер сначала проверяет, превышает ли количество входов установленный порог.
- Если это не превышает логику продолжения входа в систему, оцените правильность имени пользователя и пароля, и если пароль неверен, будет оценено пороговое значение.Это можно сделать с истечением срока действия redis.
- После успешного входа в систему выполняются все последующие пост-логики, такие как добавление баллов. . . и так далее.
Регистрация мобильного номера и вход в систему
блок-схема:
- Сначала введите номер мобильного телефона, затем отправьте его на сервер, сервер записывает номер мобильного телефона в нашу базу данных, затем генерирует случайный проверочный код, привязывает номер мобильного телефона и проверочный код к редису, а затем записывает время истечения срока действия. , это время истечения Обычно около 10 минут, что является сроком действия нашего общего кода проверки мобильного телефона.
- После того, как мобильный телефон получит текстовое сообщение мобильного телефона, он заполнит код подтверждения на интерфейсе и отправит его на сервер.После того, как сервер получит код подтверждения, он запросит код подтверждения, соответствующий номеру мобильного телефона в Redis. , В случае сбоя он вернет код ошибки.
- Войдите в систему после успеха.
Кажется, что здесь нет четкой регистрации и входа в систему, по сути, отправку номера мобильного телефона можно рассматривать как обычную регистрацию, а последующий ввод проверочного кода — как операцию входа.
просить:Что делать, если мне нужен пароль?
отвечать:Достаточно добавить функцию дополнительной записи пароля номера мобильного телефона в последующие продукты.Это также очень распространенный метод сейчас, но сейчас, в эпоху взрыва мобильного Интернета, пароль не так важен. , Я никогда не помню пароль Приложение, которым можно управлять по номеру, никогда не будет работать без пароля.
Дизайн базы данных
Структура таблицы
| идентификатор автоматического увеличения | имя пользователя | пароль | Телефонный номер | количество ошибок |
|---|---|---|---|---|
| 1 | user1 | 7fef6171469e80d32c0559f88b377245 | 13456789012 | 0 |
| 2 | user2 | 7fef6171469e80d32c0559f88b377245 | 13456789013 | 0 |
инструкция
- Это всего лишь простое описание данных, которые необходимо использовать, и никакие конкретные сценарии не расширяются.Эта структура таблицы может соответствовать дизайну двух вышеуказанных схем.
Внедрение сторонних решений для учетных записей
Вот логика входа в QQ-SDK, Начнем с волны временных диаграмм
инструкция:
- Клиент вызывает интерфейс входа в систему и вводит имя пользователя и пароль. Здесь имя пользователя и пароль третьей стороны. После успешного входа он вернет access_token openid expire_in. Этот процесс будет использовать oauth2.0, но в sdk Получен встроенный обратный вызов, и мы объясним нашу собственную реализацию oauth2.0 позже
- Клиент получает access_token, openid, login_type (qq, wechat...) и запрашивает сервер приложений.После того, как сервер приложений получит данные, он отправится в соответствующий пользовательский центр для проверки access_token и openid в соответствии с соответствующим login_type . Если проверка не пройдена, будет возвращен соответствующий код ошибки.
- После того, как проверка будет пройдена, он определит, существуют ли локально login_type и openid, если они не существуют, то в качестве локальных базовых данных будет получено имя удаленного пользователя, аватар и другая базовая информация, а значение кода будет возвращено.
- Если он уже существует, он должен выполнить операцию входа в систему и вернуть значение кода.
- После получения клиентом значения кода происходит обмен значением токена.Это полностью соответствует протоколу oauth2.0.Каждый последующий запрос должен приносить токен.Значение токена долго находится на стороне сервера,потому что мы хотим сделать Это такая операция, которая никогда не переходит в автономный режим, поэтому мы накапливаем время истечения срока действия токена для каждого запроса.
Дизайн базы данных
Структура таблицы
По предложению из офиса комментариев @ не могу попрощаться 1486617502000, я сделаю здесь некоторую сортировку базы данных Базовая таблица пользователей (пользователи)
| поле | Примечание |
|---|---|
| user_id | Идентификатор пользователя |
| token | Токен входа пользователя |
| expire_in | срок действия токена |
| try_times | Ошибки входа |
Таблица ассоциации аутентификации пользователя (user_auth_rel)
| поле | Примечание |
|---|---|
| id | идентификатор автоматического увеличения |
| user_id | Идентификатор пользователя |
| auth_id | проверить идентификатор таблицы |
| auth_type | Тип аутентификации (локальная, третья) |
Локальная таблица пользователей (user_local_auth)
| поле | Примечание |
|---|---|
| auth_id | Идентификатор аутентификации, идентификатор автоинкремента |
| user_name | Уникальный идентификатор пользователя |
| password | пользовательский пароль |
| mobile | Мобильный телефон пользователя |
Таблица сторонних пользователей (user_ Third_auth)
| поле | Примечание |
|---|---|
| auth_id | Идентификатор пользователя |
| openid | Уникальный идентификатор стороннего пользователя |
| login_type | Идентификация сторонней платформы (qq, wechat...) |
| access_token | Access_token, полученный третьей стороной, используется для проверки |
инструкция
- Таблица пользователей предназначена только для входа в систему нашей бизнес-стороны, в основном для бизнеса oauth2.0 нашего собственного бизнеса.
- user_local_auth должен войти в систему с вашим собственным именем пользователя и паролем, а также войти в систему с вашим номером мобильного телефона.
- user_ Third_auth — это запись данных нашей сторонней пользовательской системы,
- user_auth_rel используется для связывания нашей таблицы пользователей с user_local_auth, user_ Third_auth.
- Вся концепция дизайна состоит в том, чтобы отличить самодельных пользователей от сторонних хранилищ, что также разумно с точки зрения эволюции архитектуры.Вначале большинство пользовательских систем строятся самостоятельно, а затем осуществляется внешний доступ.
Суммировать
- Вообще говоря, технология доступа сторонних пользователей относительно проста.Еще один user_ Thirds разработан здесь, чтобы поддерживать достаточное количество стороннего доступа.Конечно, как правило, нам нужно только два или три входа в систему, слишком много входов.Fang не только имеет свой собственные расходы на техническое обслуживание, но и макет интерфейса не очень красивый.
- Я надеюсь, что каждый может извлечь уроки из вышеизложенного и хорошо понять наш вход в систему с несколькими учетными записями.Дизайн здесь не включает подтаблицы и подбазы данных, не сервис, а простой и прямой дизайн.Конечно, число пользователей и потребности разные.Есть еще многое, что можно добавить к этой основе, спасибо за чтение! ! !