Предисловие:
Эта статья переведена сLydia Hallieнаписано госпожой.✋🏼🔥 Визуализация CS: CORS, Она использовала множество анимаций, чтобы объяснить концепцию CORS. Никто в Китае не переводил эту статью, поэтому я перевел эту статью и исправил некоторые ошибки, исходя из моего понимания исходного текста, в надежде помочь всем.
по-моему хороший переводНравится, спасибо, это действительно много значит для меня! 🌟
Примечание. Все исходные анимацииkeynoteсделать
Во фронтенд-разработке мы часто используем данные с других сайтов. Прежде чем внешний интерфейс сможет отобразить эти данные, необходимо отправить запрос на сервер, чтобы получить эти данные.
Допустим, мы в гостяхhttps://api.mywebsite.comэтот сайт, нажмите кнопку, чтобыhttps://api.mywebsite.com/usersОтправьте запрос на получение информации о пользователе на сайте:
⚠️: Здесь автор оригинала сделал опечатку.
https://api.mywebsite.comнаписано с ошибкой какhttps://www.mywebsite.com, на картинке тоже есть эта ошибка, читатель должен быть осторожен, чтобы не быть введенным в заблуждение
По результатам производительность идеальная, мы отправляем запрос на сервер, сервер возвращает нужные нам данные в формате JSON, а интерфейс нормально отрисовывает результат.
Попробуем другой сайт. использоватьhttps://www.anotherwebsite.comЭтот сайт направлен наhttps://api.website.com/usersпослать запрос:
Вот такая проблема, мы запрашиваем тот же интерфейс сайта, но на этот раз браузер выдает нам Error.
Ошибка CORS, выданная браузером только что, давайте проанализируем, почему возникает эта ошибка и каково точное значение этой ошибки.
1. Та же политика происхождения
Когда браузер делает сетевой запрос,Та же политика происхожденияМеханизмы. То есть по умолчанию веб-приложение, использующее API, может запрашивать ресурсы HTTP только из того же домена, который загружает приложение.
Например,https://www.mywebsite.comпроситьhttps://www.mywebsite.com/pageНет абсолютно никаких проблем. Но когда ресурс находится в другомпротокол,Субдоменыилипорт, запрос является междоменным.
В настоящее время политика одного и того же происхождения ограничивает три варианта поведения:
- Файлы cookie, LocalStorage и IndexDB имеют ограниченный доступ
- Невозможно манипулировать DOM из разных источников (обычно для фреймов).
- Запросы XHR и Fetch, сделанные Javascript, ограничены
Итак, почему существует политика одного и того же происхождения?
Давайте предположим, что если нет стратегии того же происхождения, вы случайно нажали ссылку на статью о здоровье, которую Ци Да Гу прислал вам в WeChat. На самом деле эта веб-страница является фишинговым веб-сайтом, после перехода по ссылке он перенаправляет вас на веб-сайт атаки, встроенный в iframe, который автоматически загружает веб-сайт банка и выполняет вход в вашу учетную запись через файлы cookie.
После успешного входа в систему этот фишинговый веб-сайт также может контролировать DOM iframe и переводить деньги на вашу карту с помощью ряда хитрых операций.
Это очень серьезное нарушение безопасности, и мы не хотим, чтобы к нашему контенту в Интернете обращались случайно, не говоря уже о веб-сайте, связанном с деньгами.
Политика того же источника может помочь нам решить эту проблему безопасности, эта политика гарантирует, что мы можем получить доступ к ресурсам только с одного и того же сайта.
при этих обстоятельствах,https://www.evilwebsite.comпопробуй межсайтовый доступhttps://www.bank.comресурсы, политика того же происхождения предотвратит эту операцию, чтобы фишинговый сайт не мог получить доступ к данным сайта банка.
Сказав это, какое отношение политика одного и того же происхождения имеет к CORS?
2. CORS браузера
Ограничения браузера по соображениям безопасностиИнициировать из скриптамеждоменных HTTP-запросов. Например, XHR и Fetch следуют политике одного и того же источника. Это означает, что веб-приложение, использующее API, может запрашивать ресурсы HTTP только из того же домена, который загружает приложение.
При ежедневном развитии бизнеса мы часто обращаемся к ресурсам из разных источников.Чтобы безопасно запрашивать ресурсы из разных источников, браузеры используют механизм, называемый CORS.
Полное название CORSCross-Origin Resource Sharing,Прямо сейчасСовместное использование ресурсов между источниками. Хотя по умолчанию браузеры запрещают нам доступ к ресурсам из разных источников, мы можем воспользоваться преимуществом CORS.расслаблятьсяЭто ограничение разрешает доступ к междоменным ресурсам с целью обеспечения безопасности.
Браузеры могут использовать механизм CORS, чтобы обеспечить совместимый междоменный доступ и предотвратить несоответствующий междоменный доступ. Что происходит внутри браузера? Давайте проанализируем это ниже.
После того как веб-программа сделает междоменный запрос, браузеравтоматическийДобавьте дополнительное поле заголовка запроса в наш HTTP-заголовок:Origin.OriginЗапрошенный источник сайта помечен:
GET https://api.website.com/users HTTP/1/1
Origin: https://www.mywebsite.com // <- 浏览器自己加的
Чтобы браузер разрешил доступ к ресурсам из других источников, в ответ, возвращаемый сервером, также необходимо добавить некоторые поля заголовка ответа, которые будутявно указатьРазрешает ли этот сервер этот перекрестный запрос.
3. Сервер CORS
Как разработчик сервера, мы можем сделать это, добавив дополнительные поля заголовка ответа в ответ HTTP.Access-Control-*чтобы указать, разрешены ли междоменные запросы. На основе этих полей заголовка ответа CORS браузеры могут разрешать некоторые ответы из разных источников, которые ограничены политикой одного и того же источника.
Хотя естьНесколько полей заголовка ответа CORS, но одно поледолжен добавитьда, этоAccess-Control-Allow-Origin. Значение этого поля заголовка указывает, каким сайтам разрешен доступ к ресурсу через домены.
1️⃣ Если у нас есть разрешение на разработку сервера, мы можем датьhttps://www.mywebsite.comПлюс доступ: добавьте домен вAccess-Control-Allow-Originсередина.
Это поле заголовка ответа теперь добавляется к заголовку ответа, который сервер отправляет обратно клиенту. После добавления этого поля, если мы начнемhttps://www.mywebsite.comОтправляйте междоменные запросы, гомологичные стратегии больше не будут ограничиватьhttps://api.mywebsite.comРесурсы сайта возвращены.
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://www.mywebsite.com
Date: Fri, 11 Oct 2019 15:47 GM
Content-Length: 29
Content-Type: application/json
Server: Apache
{user: [{...}]}
2️⃣ После получения ответа, возвращенного сервером, механизм CORS в браузере проверитAccess-Control-Allow-OriginЗначение равно значению в запросеOriginценность .
В этом примере запросOriginдаhttps://www.mywebsite.com, то же самое, что и в ответAccess-Control-Allow-OriginЗначение одинаково:
3️⃣ Верификация браузера пройдена, и интерфейс успешно получает междоменный ресурс.
Ну, когда мы пытаемся получить отAccess-Control-Allow-OriginЧто происходит, когда сайты, перечисленные в междоменном доступе к этим ресурсам?
Как показано выше, изhttps://www.anotherwebsite.comмеждоменный доступhttps://api.mywebsite.comресурс, браузер выдает ошибку CORS, после приведенного выше объяснения мы можем прочитать сообщение об ошибке:
The 'Access-Control-Allow-Origin' header has a value
'https://www.mywebsite.com' that is not equal
to the supplied origin.
при этих обстоятельствах,OriginЗначениеhttps://www.anotherwebsite.com. Тем не менее, серверAccess-Control-Allow-OriginСайт не отмечен в поле заголовка ответа, механизм CORS браузера блокирует этот ответ, и мы не можем получить данные ответа в нашем коде.
CORS также позволяет нам добавлять подстановочные знаки
*В качестве разрешенного внешнего домена это означает, что ресурс может бытьЛюбыеДоступ вне домена, так что помните об этом особом случае
Access-Control-Allow-Origin— одно из многих полей заголовка, предоставляемых механизмом CORS. Разработчики серверов также могут расширить политику CORS сервера дополнительными полями заголовков, чтобы разрешать/запрещать определенные запросы.
Другим распространенным полем заголовка ответа являетсяAccess-Control-Allow-Methods. Он определяет методы HTTP, разрешенные для запросов между источниками.
Только в случае вышеGET,POSTилиPUTМетодам разрешен доступ к ресурсам через домены. другие методы HTTP, такие какPATCHа такжеDELETEбудет заблокирован.
Если вы хотите узнать, что представляют собой другие поля заголовка ответа CORS и для чего они используются, вы можетеПосмотреть этот список.
Говоря оPUT,PATCHа такжеDELETEСуществуют некоторые различия в том, как CORS обрабатывает эти HTTP-методы. Эти непростые запросы инициируют предварительные запросы CORS.
4. Предварительный запрос
CORS имеет два типа запросов: одинпростой запрос, одинпредварительный запрос. Является ли запрос между источниками простым или предварительным, зависит от некоторых заголовков запроса.
когда запросGETилиPOSTметод и без каких-либо настраиваемых полей заголовка, как правило, это простой запрос. Любой другой запрос, напримерPUT,PATCHилиDELETEметод, создаст предварительную проверку.
Если вы хотите узнать, каким требованиям должен соответствовать запрос, чтобы быть простым запросом, вы можете проверить MDNпростой запросСвязанныйДокументация.
сказав так много"предварительный запрос"Что именно это означает? Давайте обсудим это ниже.
1️⃣ Перед отправкой фактического запроса клиент будет использоватьOPTIONSметод инициирует предварительный запрос, предварительный запросAccess-Control-Request-* содержит информацию о фактическом запросе, который мы собираемся обрабатывать:
- поле заголовка
Access-Control-Request-MethodСообщите серверу, что фактический запрос будет использоватьсяметодчто - поле заголовка
Access-Control-Request-Headersсообщить серверу, что фактический запрос будет сопровождатьсяПользовательские поля заголовка запросачто
OPTIONS https://api.mywebsite.com/user/1 HTTP/1.1
Origin: https://www.mywebsite.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type
2️⃣ После того, как сервер получит предварительный запрос, он вернет HTTP-ответ без тела, в котором отмечены методы HTTP и поля HTTP-заголовка, разрешенные сервером:
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://www.mywebsite.com
Access-Control-Request-Method: GET POST PUT
Access-Control-Request-Headers: Content-Type
3️⃣ Браузер получает предварительный ответ и проверяет, следует ли разрешить отправку фактического запроса.
⚠️: Отсутствует ответ предварительной проверки на картинке выше.
Access-Control-Allow-Headers: Content-Type
4️⃣ Если предпечатное обнаружение ответа пройдет, браузер отправит фактический запрос на сервер, а затем сервер вернет нужные нам ресурсы.
Если ответ на предварительную проверку завершится неудачно, CORS предотвратит доступ к другому источнику, и фактический запрос никогда не будет отправлен. Предварительные запросы — отличный способ предотвратить доступ или изменение ресурсов на серверах, на которых не включены политики CORS.
💡 Чтобы уменьшить количество сетевых циклов, мы можем сделать это, добавив в запрос CORS
Access-Control-Max-Ageполя заголовка для кэширования ответов предварительной проверки. Браузеры могут использовать кэширование вместо отправки новых предварительных запросов.
5. Сертификация
Интересная особенность XHR или Fetch и CORS заключается в том, что мы можемCookiesи информацию об аутентификации HTTP для отправки учетных данных. Как правило, для запросов XHR или Fetch из разных источников браузерНе будетОтправьте учетную информацию.
Хотя CORS не отправляет учетные данные по умолчанию, мы можем сделать это, добавивAccess-Control-Allow-CredentialsЗаголовок ответа CORS, чтобы изменить его.
Чтобы включить файлы cookie и другую информацию для авторизации в междоменные запросы, нам необходимо сделать следующее:
- Генерал-лейтенант запросов XHR
withCredentialsполе установлено наtrue - Генерал-лейтенант по запросам на получение
credentialsустановить какinclude - сервер поставить
Access-Control-Allow-Credentials: trueдобавить в заголовок ответа
// 浏览器 fetch 请求
fetch('https://api.mywebsite,com.users', {
credentials: "include"
})
// 浏览器 XHR 请求
let xhr = new XMLHttpRequest();
xhr.withCredentials = true;
// 服务器添加认证字段
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
После выполнения вышеуказанной работы мы можем включить учетные данные в междоменный запрос.
6. Резюме
Ошибка CORS в определенной степени затруднит разработку внешнего интерфейса, но после соблюдения соответствующих правил она позволяет нам выполнять безопасные междоменные запросы в браузере.
Есть много знаний о стратегии гомологии и CORS. В этой статье рассказывается только о некоторых ключевых знаниях. Если вы хотите всесторонне узнать о CORS, я рекомендую вам проверить это.Документация MDNа такжеСпецификация W3C, это знание из первых рук является наиболее точным.
7. Наконец
Это конец этой статьи. Если вы считаете, что это хорошо, не забудьте поставить большой палец вверх и поощрить. Желаю вам удачи в учебе и работе!
Если вы хотите узнать больше о HTTP, не связанном с ноутбуком, вы можете просмотреть старые статьи, которые я написал ранее:
- Получает ли X-Forwarded-For настоящий IP-адрес?
- В HTTP-запросах должны ли пробелы кодироваться как %20 или +?
- Вы наступали на эти ямы HTTP?
Напоследок рекомендую волну моего личного номера:Яйцо Лаборатории (Egglabs), обновит некоторые статьи, связанные с передовыми технологиями и графикой, оригинальным созданием без орошения, приглашаю всех обратить внимание.