Лю Нипин: главный инженер отдела передовых технологий WeDoctor. Разводить рыбу, цветы и собак, допоздна танцевать и пить. Уехав на полжизни, я вернулся с трехлетним опытом фронтенд-работы.
Первая глава
Рождение файлов cookie и их характеристики
Как мы все знаем, веб-серверынет статусаДа, stateless означает, что сервер не знает, что пользователь делал в последнем запросе, каждый запрос не зависит друг от друга, а информация о клиенте поступает только изпо запросуОн переносится во время, или общедоступная информация хранится на самом сервере и может использоваться всеми запросами. Таким образом, для отслеживания информации о статусе, запрошенной пользователем, например, для записи истории покупок пользователя в онлайн-магазине, появились файлы cookie.
Когда сервер отвечает на запрос клиента, он отправляет клиенту файл cookie. Этот файл cookie записывает некоторую информацию на сервере. Клиент передает этот файл cookie в последующих запросах. Сервер может судить о контексте запроса в соответствии с этим файлом cookie. связь.
Появление файлов cookie — это средство перехода от состояния без сохранения состояния к состоянию с сохранением состояния.
В качестве примера для входа в систему пользователь вводит имя учетной записи и пароль, отправляет запрос на сервер, сервер генерирует файл cookie и отправляет его в браузер, а браузер сохраняет файл cookie в виде kv в текстовый файл в определенного каталога и запрашивает тот же веб-сайт в следующий раз, чтобы отправить файл cookie на сервер. Сервер проверяет, соответствует ли полученный файл cookie серверному файлу cookie. Если он несовместим, проверка завершается неудачно. Это оригинальная идея.
Файлы cookie хранятся в браузере в месте, показанном на изображении ниже.
Принцип Cookie определяет, что он имеет следующие характеристики:
1. Хранится на клиенте, может быть изменен по желанию, не безопасно
2. Его содержимое будет передаваться через HTTP-взаимодействие, что повлияет на производительность, поэтому данные, которые могут храниться в файле cookie, не должны быть слишком большими, максимум — 4 КБ.
3. Браузер может хранить не более 20 файлов cookie для веб-сайта, а браузеры обычно позволяют хранить только 300 файлов cookie.
4. Мобильный терминал не поддерживает поддержку файлов cookie.
5. Как правило, сохраняется обычный текст, объекты должны быть сериализованы, прежде чем их можно будет сохранить, а синтаксический анализ должен быть десериализован.
Обмен файлами cookie между доменами второго уровня
Возьмем в качестве примера файл cookie для входа. Например, есть два доменных имени второго уровня.http://a.xxx.com(Домен А) иhttp://b.xxx.com(Домен Б). Итак, можно ли использовать файл cookie для входа в домен A в домене B?
По умолчанию файл cookie, сгенерированный узлом службы доменного имени A, может быть получен только сервером доменного имени A, а другие доменные имена не могут получить файл cookie.Файлы cookie только для хоста.
Но сервер может определить свой домен, явно объявив домен файла cookie, как в приведенном выше примере,Set-CookieУстановите для домена A имя домена cookie для входа в системуhttp://xxx.com(ихобщий домен верхнего уровня), путь установлен на’/’,Set-Cookie： name=value;domain=xxx.com;path=’/’, то доменное имя B сможет его прочитать.
в новой спецификацииrfc6265, стоимость доменабудет игнорировать любые начальные точки, то есть,**xxx.com**а также**.xxx.com**Оба доступны в поддоменах. SSO (единый вход) также основан на этом принципе.
Например, теперь есть два доменных имени,a.b.e.f.com.cn(Домен 1) иc.d.e.f.com.cn(доменное имя 2), доменное имя 2 хочет прочитать файлы cookie доменного имени 1, какие домены может объявить доменное имя 1? ответ.e.f.com.cnили.f.com.cn, браузер не может принимать куки-файлы с доменом .com.cn, потому что, если домен куки-файла может быть установлен на суффикс, это каньонная битва.
тогда, если домен 1 установленSet-Cookie： mykey=myvalue1;domain=e.f.com.cn;path=’/’
Настройки домена 2Set-Cookie： mykey=myvalue2;domain=e.f.com.cn;path=’/’
Тогда значение mykey под доменом будет перезаписано как myvalue 2. Понятно, что под одним и тем же доменом mykey куки уникален.Обычно мы хотим уменьшить ненужную передачу данных и сэкономить пропускную способность, установив правильный домен и путь.
Принцип сеансового режима cookie
С появлением интерактивных веб-приложений, ограничением размера файлов cookie и ограничением количества файлов cookie, хранимых браузерами, нам необходимо более мощное пространство для хранения большого объема пользовательской информации, например, кто вошел на наш веб-сайт и чей корзина покупок Добавить товары и т. д., сервер должен хранить информацию о десятках миллионов или даже большем числе пользователей, а куки явно неприемлемы. тогда что нам делать?
Представьте, что мы находим место на стороне сервера для хранения информации о состоянии всех пользовательских сеансов и назначаем каждому пользователю разные «идентификаторы», то есть sessionId, а затем передаем этот идентификатор сеанса клиенту браузера, чтобы сохранить его в файле cookie. для записи текущего В следующем запросе вам нужно только нести этот идентификатор сеанса, и сервер может перейти в это пространство для поиска пользователя, соответствующего идентификатору. ** Это может не только решить проблему ограничения файлов cookie, но и не требует раскрытия информации о пользователе клиенту, что значительно повышает практичность и безопасность.
Где хранится информация о пользователе? Может ли он существовать прямо на сервере?
Если он существует на сервере, 1. Это огромные накладные расходы для сервера, которые серьезно ограничивают возможности расширения сервера. 2. Предполагая, что нагрузка на веб-сервер сбалансирована, пользователь user1 входит в систему через машину A, тогда, если следующий запрос перенаправляется на другую машину B, информация о пользователе не сохраняется на машине B, поэтому ее невозможно найти. sessionId, поэтому sessionId не должен храниться на сервере. В настоящее времяredis/MemcachedВышло решить проблему, можно просто понять их каккешировать базу данных.
Когда мы централизованно храним sessionId на независимом кэш-сервере, все машины обращаются к этой системе кэширования для получения информации о пользователе и аутентификации в соответствии с sessionId. Тогда проблема решена.
Принцип работы принципа работы Cookie-сессии
По принципу работы вы нашли что-то подобное?
Это увеличивает вероятность сбоя единого входа.Если машина, отвечающая за сеанс, зависнет, весь вход в систему зависнет. Но обычно в проекте машина, отвечающая за сеанс, также является кластером из нескольких машин для балансировки нагрузки для повышения надежности.
думать:
Будет ли потеряна информация о пользователе при перезапуске сервера?
У Redis и других кеш-серверов тоже есть кластер. Предположим, что служба перезапускается, и она будет искать информацию о пользователях с других работающих серверов. Предположим, что все серверы рухнули одновременно, что мне делать? Общая стратегия преодоления заключается в том, что пользовательская информация, хранящаяся в памяти, будет периодически сбрасываться на жесткий диск хоста для сохранения данных.Даже если они будут потеряны, будут потеряны только пользовательские данные в течение нескольких минут после перезапуска.
Ограничения сеанса cookie
1. Опираясь на файлы cookie, пользователи могут отключить файлы cookie на стороне браузера.
2. Не поддерживает кросс-совместимые приложения и т. д.
3. Бизнес-система продолжает запрашивать кэш-сервер для поиска информации о пользователе, что увеличивает нагрузку на память и создает чрезмерную нагрузку на сервер.
4. Сервер stateful.Если нет кэш-сервера, очень сложно расширить емкость.Необходимо скопировать sessionId в несколько серверов.
5. Существует вероятность сбоя единого входа
Глава 2
Три типа SSO (Single Sign On)
Единый вход или SSO для краткости. С развитием предприятия большая система может содержать n нескольких подсистем.Когда пользователи работают с разными системами, им необходимо многократно входить в систему, что очень хлопотно.Для решения этой проблемы используется единый вход.В системах с несколькими приложениями вам нужно только один раз войти в систему, чтобы получить доступ к другим взаимно доверенным системам приложений.
Как мы уже говорили ранее, единый вход основан на обмене файлами cookie с доменом верхнего уровня, которые можно разделить на следующие три типа в зависимости от различных ситуаций.
1. Под тем же сайтом;
2. Система находится под одним и тем же доменным именем верхнего уровня;
3. Каждая подсистема принадлежит разным доменным именам верхнего уровня.
Как правило, у предприятия есть одно доменное имя верхнего уровня.Как упоминалось ранее, единый вход под одним и тем же сайтом и одним и тем же доменом верхнего уровня использует функцию совместного использования домена верхнего уровня cookie.Я думаю, что все уже это понимают. процесс и не будет их повторять. Но что, если это другой домен? Файлы cookie не распределяются между разными доменами, что мне делать?
Принцип CAS (Центральная служба аутентификации)
Здесь речь пойдет о CAS (Центральная служба аутентификации), этот процесс является стандартным процессом единого входа. Он использует отдельную систему специально для аутентификации, далее именуемую системой SSO.
Его процесс на самом деле такой же, как в режиме сеанса Cookie-Session. Один наход означает, что каждая подсистема имеет полный набор режима сеанса cookie, а также набор SSO системы Cookie-сеанса.
Пользователь получает доступ к системе a и переходит к системе единого входа, когда ему необходимо войти в систему. После прохождения аутентификации учетной записи и пароля в системе единого входа сервер единого входа сохраняет сеанс, генерирует идентификатор сеанса и возвращает его браузеру единого входа, а затем браузер записывает SSO Cookie под доменом и генерирует ST, переносит ST в систему a, система a использует этот ST для запроса системы SSO для проверки, после успешной проверки серверная часть системы a записывает логин статус сеанса и типы Cookie под системным доменом. После этого, когда система снова выполняет проверку входа, это аутентификация в том же домене.
В это время пользователь обращается к системе b, и когда он переходит к SSO для входа в систему, он обнаруживает, что SSO уже вошел в систему, затем SSO генерирует ST, переносит ST в систему b, а система b использует ST для запроса системы SSO для проверки.После успешной проверки серверная часть системы b записывает статус входа в сеанс и устанавливает cookie в домене системы b. Видно, что в этом процессе системе b не нужно снова входить в систему.
Что касается "Я обнаружил, что SSO уже вошел в систему, когда я перешел к SSO для входа", как это делается? Это связано с механизмом авторизации Oauth2. Когда система переходит, пусть она переходит из системы a, переходит к SSO с сеансом информацию о системе a, а затем перенаправить обратно в систему b.
Об Oauth2 вы можете узнать у Руана Ифэна.Четыре способа OAuth 2.0".
Глава 3
Мы проанализировали ограничения Cookie-сессии, есть ли более основательное решение? Поскольку наличие системы аутентификации SSO увеличивает вероятность единой точки отказа, не должна ли она нам просто не понадобиться? В этом заключается идея децентрализации, то есть кеш-сервер, используемый для хранения и проверки информации о пользователях, опускается, а проверка выполняется в соответствующих системах другим способом. Метод реализации заключается в том, чтобы просто зашифровать всю информацию о сеансе в файл cookie, отправить его в браузер и обменять вычислительную мощность ЦП на пространство.
Шаблон веб-токена Json
Сервер не сохраняет sessionId. После входа пользователя в систему сервер выдает ему токен. При следующем обращении пользователя к серверу через HTTP-запрос токен будет передан через Http-заголовок или URL-адрес для подтверждения. Чтобы предотвратить подделку другими, мы можем добавить ключ, известный только нам, к данным, сделать подпись и отправить данные вместе с подписью в виде токена. Таким образом, нам не нужно сохранять токен, потому что токен, отправленный пользователю, уже содержит информацию о пользователе. Когда пользователь снова запрашивает, я использую тот же алгоритм и ключ для шифрования данных в токене.Если зашифрованный результат согласуется с подписью в токене, то мы можем аутентифицировать пользователя и получить от него информацию.
Для сервера это отвечает только за генерацию токена, а затем проверку токена, и для хранения большого количества сессий не требуется дополнительный кеш-сервер, при увеличении трафика нам нужно только расширить мощность сервера с большой спрос на доступ Это более экономично, чем расширять сервер всего пользовательского центра.
Если кто-то подделал информацию о пользователе, но поскольку ключ неизвестен, подпись в токене и подпись, вычисленная клиентом после подделки, должны быть несовместимы, и аутентификация не удастся, поэтому не нужно беспокоиться о проблемах безопасности. .
По поводу своевременности токена так и сделано.При первом входе генерируется токен на основе пароля учетной записи.При каждом последующем запросе сервер обновляет метку времени и отправляет новый токен, а клиент заменяет оригинальный токен.
Блок-схема принципа работы JWT
Какова выгодная ситуация jwt?
недостатки
1. Выход из режима jwt на самом деле является фальшивым сбоем входа в систему, потому что это просто иллюзия, сформированная очисткой токена на стороне браузера.Если используется предыдущий токен, вход в систему может быть успешным, пока не истек срок его действия.
2. Безопасность зависит от ключа, как только ключ открыт
3. Данные, генерируемые шифрованием, относительно длинные и занимают относительно больше трафика.
преимущество
1. Не использует файлы cookie, может применяться в разных терминалах и программах и поддерживает мобильные устройства.
2. По сравнению с режимом сеанса cookie без единого входа, его очень легко расширить.
3. Сервер поддерживает функцию без сохранения состояния, и ему не нужно хранить информацию о пользователе на сервере или в сеансе.
4. Сохраните много запросов для режима, который должен постоянно отправлять запросы аутентификации на сайт SSO для единого входа.
Зайдите на онлайн-платформу диагностики и лечения интернет-клиники WeDoctor, проведите быструю консультацию и за 3 минуты найдите для себя врача из тройки лучших.