Полный процесс нескольких способов входа в бизнес

внешний интерфейс Vue.js опрос
Полный процесс нескольких способов входа в бизнес

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

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

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

Чтобы решить эту проблему, нам нужны некоторые решения для записи статуса входа в систему.

Таким образом, эта статья начнется с трех аспектов

  • В первой главе в основном рассказывается, как войти в систему с помощью нескольких различных методов входа при вызове интерфейса входа в систему.
  • Во второй главе в основном представлены несколько методов и различий последующего статуса входа в систему проверки интерфейса.
  • Третья глава в основном знакомит с единым входом в систему, потому что он немного особенный, поэтому он представлен отдельно.

Давайте узнаем вместе

Процесс первого входа

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

Логин пароль от учетной записи

Это не продемонстрирует код, соберет логин и пароль, введенные пользователем, отправит в бэкенд и базу данных для сравнения и проверки, существует ли пользователь и правильный ли пароль, все ОК вернет логин информация об успехах и пользователях и т. д.

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

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

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

Это также просто, без демонстрации кода, например, для входа в систему с кодом подтверждения мобильного телефона.

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

Некоторые люди здесь сохраняют номер мобильного телефона и случайный номер в базе данных в обратном вызове при успешной отправке стороннего SMS Некоторые люди сохраняют номер и случайное число в базе данных после генерации случайного числа, и обратный вызов, возвращенный третьей стороной, будет использоваться снова.updateодин раз

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

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

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

Быстрый вход в сторонний аккаунт

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

Такие как QQ, WeChat

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

Пример адреса для входа в QQ

https://graph.qq.com/oauth2.0/show?which=Login&display=pc&response_type=code&client_id=101958498&redirect_uri=http%3A%2F%2Fniuj.uuuqwr.cn%2Findex.html%23%2Foauth_login%2Fqq&state=24c123db52d1136c7560638325fbdab4&scope=get_user_info,list_album,upload_pic

Следует отметить, что этот адрес обратного вызова (redirect_uri), это должна быть отдельная выделенная страница в вашем проекте, которая должна получать параметры, полученные по ссылке обратного вызова после успешного входа в систему, и выполнять некоторые операции.Изменить статус входа, а не страницу входа или личный центр вашего проекта какой-то тип из

Затем, например, если вы нажмете QQ для входа в систему, вы сразу перейдете к сторонней ссылке для входа, возвращаемой серверной частью, которая выглядит следующим образом.

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

Внешний интерфейс находится на этой странице адреса возврата, и после его получения он передается на серверную часть, а затем серверная часть настраивает сторонний интерфейс для получения информации о вошедшем в систему пользователе.openId,unionId, по сравнению с базой данных, зарегистрируйте пользователя без нее и сохраните ееopenId,unionId

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

Например, логин WeChat, согласно возвращенному серверуredirect_uriа такжеAppIdи другую информацию, сгенерируйте QR-код на текущей странице или откройте новую вкладку, чтобы перейти на отдельную страницу кода сканирования.

Например, для создания QR-кода на текущей странице я использую следующее:vue-wxlogin, установить сначала

npm install vue-wxlogin --save

затем используйте

<template>
  <wxlogin
    :appid="appid"
    :scope="scope"
    :redirect_uri="redirect_uri"
    self_redirect="false"
    theme="white"
  ></wxlogin>
</template>
<script>
import wxlogin from "vue-wxlogin";
export default {
  data(){
    return {
      appid: "wx989xxxxxxxxx",
      scope: "snsapi_login",
      redirect_uri: encodeURIComponent(
        "http://xxxxxx/index.html#/oauth_login/wx"
      )
    }
  }
}
</script>

После того, как QR-код будет сгенерирован, третья сторона начнет опрос следующим образом.

Затем процесс после сканирования кода для входа в систему в основном такой же, как и процесс после быстрого входа в QQ.

Вход по скан-коду приложения

Во-первых, вам нужно сгенерировать двумерный код, который я использую здесь:vue-qr, установить сначала

npm install vue-qr --save

затем используйте

<template>
  <vue-qr 
    :text="qrCode.url" 
    :margin="5" 
    colorDark="#222" 
    colorLight="#fff" 
    :logoSrc="qrCode.icon" 
    :logoScale="0.2" 
    :size="180"
  ></vue-qr>
</template>
<script>
import VueQr from "vue-qr";
export default {
  data(){
    return {
      qrCode:{
        url:'',
        icon:'',// 就是二维码中间的图片,可以不要
      }
    }
  },
  mounted(){
    this.getQrCodeInfo() // 调接口获取生成二维码所需的信息
  }
}
</script>

Процесс такой

  • Чтобы войти на страницу, сначала получите информацию, необходимую для генерации QR-кода, настройте интерфейс

  • Затем внутренний uuid генерирует подобное и устанавливает время истечения срока действия, хранящееся в кеше, и возвращает информацию другому внешнему uuid.

  • После того, как передний конец получает информацию, она использует информацию в качестве URL в вышеуказанном коде для генерации QR-кода, а затем вызывает другой интерфейс для передачи UUID и открыть егопо-круговой,или долгое соединение, или используйте его напрямую без настройки интерфейсаWebSocketмонитор. Какой из них использовать, зависит от потребностей вашего бизнеса или переговоров с бэкэндом.

  • Тогда телефон определенно находится в состоянии входа в систему, иначе он не будет сканировать код для входа, затем сканирование приложения получит UUID в QR-коде.

  • Затем, после входа в конечную точку мобильного телефона, uuid и информация об учетной записи пользователя, зарегистрированная в конце мобильного телефона, отправляются на серверную часть.

  • Серверная часть получает информацию об учетной записи, вошедшей в систему, и отправляет ее во внешний интерфейс через WebSocket, и вход выполняется успешно. Или изменить значение в кеше.Например при сохранении uuid в качестве ключа используется uuid, а значения нет.Тогда интерфейс опроса для получения значения uuid.До входа в систему он пустой , После того, как приложение нажимает для входа, серверная часть присваивает полученную информацию о пользователе в качестве значения соответствующему uuid.Данные, опрашиваемые интерфейсной стороной, не пусты, что означает, что вход выполнен успешно, а затем back-end очищает кеш.

Вход по отпечатку пальца, вход по лицу, вход одним ключом без пароля

Это для мобильныхiOSа такжеAndroid, и оба требуютSDK

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

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

Затем пользователь нажимает авторизацию входа в один клик, сравнивает число через шлюз и возвращает результат сравнения для достижения входа в один клик.

Последующий процесс проверки входа

Существует два распространенных метода входа в систему для аутентификации:

  • Cookie + Session
  • Token

Независимо от того, какой метод входа используется, принцип проверки в настоящее время неотделим от двух вышеупомянутых

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

Cookie + Session

Процесс такой

  • После успешной первой проверки входа серверная часть создаст объект сеанса и сохранит его в кэше или базе данных.

  • Затем в заголовке ответа интерфейса входа в систему установите поле Set-Cookie, запишите в него SessionId и другую информацию и установите время истечения срока действия.Эта информация является файлами cookie, а затем браузер сохранит эту информацию о файлах cookie.

  • Затем, когда запрос будет отправлен позже, если для текущего имени домена сохранена информация о файлах cookie, браузер автоматически добавит поле cookie в заголовок запроса и выведет сохраненную информацию о файлах cookie.

  • Затем, после того, как бэкенд получит запрос, он извлечет информацию о файлах cookie в заголовке запроса и сравнит ее с соответствующей информацией о сеансе на сервере.Если они совпадают, проверка входа прошла успешно, и нет необходимости снова входить в систему. .

Например, наш Nuggets входит в систему таким образом, который возвращается интерфейсом входа Nuggets.Вы можете видеть, что есть SessionId и куча другой информации.

image.png

Недостатки этого подхода

в основномCSRF攻击: Поскольку сеанс идентифицируется на основе файлов cookie, в случае перехвата файла cookie люди могут использовать нашу информацию о файлах cookie, чтобы пропустить вход в систему, напрямую войти в состояние входа и инициировать межсайтовый поддельный запрос.

Тогда, если сессия хранится в памяти сервера, а не хранится в базе данных, будут следующие проблемы

  • 多服务器无法共享: Например, когда мы авторизуемся, то разные ресурсы на нашем сайте могут находиться на разных серверах.Когда мы запрашиваем другой сервер, в нем нет информации о сеансе, и будет считаться, что мы не авторизовались. Таким образом, и внешний код, и внутренний код могут быть размещены только на одном сервере.

  • 服务器压力大: Поскольку информация о сеансе после входа пользователя в систему сохраняется в памяти, если количество пользователей велико, нагрузка на сервер также будет увеличиваться.

Token

обработатьАналогично предыдущей сессии

  • После успешной первой проверки входа сервер обычно используетJWTШифруйте информацию о пользователе, подпись и т. д., чтобы сгенерировать строку строк, сохранить ее в базе данных и вернуть во внешний интерфейс.

  • Внешний интерфейс снова сохраняется, и есть файлы cookie, SessionStorage и LocalStorage.

  • После этого браузер не будет его нести по умолчанию при повторном запросе.Нам нужно добавить заголовок запроса в перехватчик запроса и вывести информацию о токене.

  • Затем серверная часть получает информацию о токене, чтобы узнать, есть ли какие-либо данные в базе данных. автоматически удалит токен в базе данных, когда время истечет, и запроса не будет. Конечно, есть и люди, которые открывают задачи на время для удаления.

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

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

И наоборот, если вам нужно разрешить несколько входов в систему, то есть пользователь может иметь несколько токенов.

Особенности этого метода

  • 更安全: Поскольку вы больше не можете отправлять файлы cookie, можно избежать атак CSRF. Больше не нужно управлять сеансом
  • 多服务器方便共享: Ресурсы, такие как файлы внешнего и внутреннего кода, размещаются на разных серверах, и при запросе можно получить правильный статус входа в систему.

Единый вход (SSO)

Проще говоря, учетная запись, зарегистрированная в одном приложении, может одновременно входить в несколько приложений.

Например, Taobao+Tmall+Alipay+Alibaba..., в зависимости от того, на какой из них вы войдете, а затем откроете несколько других веб-сайтов, автоматически войдет в состояние входа.

Его методы входа — это те, что представлены в первой главе этой статьи, а последующие методы проверки — те, что представлены во второй главе этой статьи, и все они были представлены.

Ключевым моментом является то, как подключить несколько приложений?

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

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

Тот же домен

Например, Baidu (baidu.com), сетевой диск Baidu (pan.baidu.com), Baidu Tieba (tieba.baidu.com), карта Baidu (map.baidu.com)...

Единый вход в этом случае

Сначала вам нужно установить файл cookie на顶级域, чтобы все поддомены под ним могли получить доступ к его файлам cookie

затем пройтиRedis,TomcatПодождите, вы можете установить общий доступ к сеансу между этими доменными именами.

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

разные домены

Например, Taobao (taobao.com), Tmall (tmall.com), Alipay (alipay.com), Alibaba (1688.com)...

В случае одного и того же домена мы также можем обмениваться файлами cookie через домен верхнего уровня, но в случае совершенно разных доменных имен файлы cookie не могут использоваться совместно, так что же нам делать?

Таким образом, чтобы решить эту проблему, нам нужна независимая система, которая может управлять или обмениваться этой информацией о состоянии унифицированным образом.认证中心(CAS), то есть,система авторизации SSO, или может пониматься как пересадочная станция

Например, теперь у нас есть два сайта: a.com и b.com, которые должны совместно использовать состояние входа.

Авторизоваться

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

sso.com?redirect_uri=a.com/user

Затем центр аутентификации обнаруживает, что в запросе на вход нет Тикета, то есть пользователь не авторизован, поэтому переходит на страницу входа, и все входы выполняются в центре аутентификации.

Затем, после того, как пользователь введет информацию и отправит заявку на вход, центр аутентификации проверит, что информация о пользователе передана, и сгенерирует билет с кодом авторизации, и запишет статус входа в центр аутентификации в файл cookie, а затем перезапишет в предыдущая страница, с билетом

a.com/user?ticket=xxxxxxx

Затем a.com/user получает билет, а затем подтверждает в центре аутентификации, действителен ли код авторизации.После успешной проверки сервер записывает информацию для входа в файл cookie и возвращает ее на внешний интерфейс для хранения. на этот раз у a.com есть два файла cookie, которые являются статусом входа в систему для вас и центра аутентификации, то есть вход в систему выполнен успешно.

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

Затем b.com также заходит на страницу, на которой нужно авторизоваться, и при перезаписи в центр аутентификации обнаруживает, что есть cookie, который был ранее авторизован, поэтому напрямую выдает Тикет на b.com

Затем b.com получает билет, а затем проверяет его в центре сертификации. Если проверка прошла успешно, он записывает информацию для входа в файл cookie и возвращает ее во внешний интерфейс для сохранения. состояние, и он не войдет на страницу входа.

выйти

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

Например, когда a.com выходит из системы, сначала очистите свой собственный файл cookie состояния входа, а затем перенесите Ticket, чтобы запросить API выхода из центра аутентификации.

Затем, после того как центр аутентификации подтвердит, что билет действителен, он проходит через все соответствующие приложения с этим кодом авторизации и вызывает соответствующий выходной API.

завершить выход из всех приложений

Преимущества и недостатки единого входа

преимущество

  • Удобный пользовательский интерфейс, не нужно запоминать несколько учетных записей и паролей
  • Повышение эффективности разработки
  • Легко управлять
CatMe
Go to work
Go to work
Me
Make tea
Make tea
Me
Go upstairs
Go upstairs
MeCat
Do work
Do work
Go home
Go home
Me
Go downstairs
Go downstairs
Me
Sit down
Sit down
My working day

недостаток

  • Это не способствует рефакторингу, потому что задействовано много систем.Если вы хотите провести рефакторинг, вам нужно быть совместимым со всеми системами, что очень хлопотно.
  • Существуют риски безопасности. В конце концов вам нужно только входить в систему только один раз, и все авторизованные приложения могут напрямую доступ к нему, что может привести к некоторой утечке информации

Прекрасное прошлое

Эпилог

Эта статья участвует вПериферийные подарки Nuggets 🎁 событиеО, просто оставьте то, что вы хотите сказать этой статье или новичкам в области комментариев этой статьи

По состоянию на 12:00 12 сентября два случайных работника в области комментариев могут напрямую бесплатно получить новую версию значка Nuggets.

хдм, давай вместе

Ставь лайк и поддержи, оставь аромат в руке и будь почетным

Спасибо за то, что вы здесь!