[МУЗЫКА]
Давайте поговорим на каком-то языке CORS.
Что именно такое совместное использование результатов перекрестного происхождения и
почему это актуально, когда мы смотрим на веб-приложения и
гипермобильные приложения, как мы делали в этой специализации?
Как вы понимаете, большинство веб-страниц теперь тянут данные со
многих разных сайтов, чтобы построить веб-страницу.
Теперь, чтобы навязать строгую политику доступа к ресурсам с разных сайтов, одна и
та же политика происхождения была навязана многими браузерами.
Мы поговорим немного об этом более подробно в следующих нескольких слайдах, но
в контексте фреймворков, которые мы обсуждали в этой конкретной
специализации, таких как Angular, Ionic и NativeScript,
многие из них будут включать скрипты, JavaScript код,
который может быть доступ к ресурсам с разных сайтов.
И именно здесь проблема CORS возникает очень легко.
Давайте посмотрим, как мы рассмотрим эту проблему более подробно в этой лекции и
упражнении, которое следует за ней.
Я кратко сослался на политику того же происхождения, что я начал эту лекцию.
Теперь политика одного происхождения представляет собой модель безопасности веб-приложения,
которая ограничивает
взаимодействие документа или скрипта, загруженного из одного источника, с ресурсами из другого источника.
Цель этого состоит в том, чтобы изолировать потенциально вредоносные документы.
Теперь, очевидно, когда у вас есть веб-страница, которая включает в себя скрипт,
код JavaScript, который может получить доступ к ресурсам из другого места,
потенциально вредоносный код может быть введен на вашу веб-страницу и
таким образом получить доступ к другому происхождению, чем от того, где ваша веб-страница получена.
Теперь, по этой причине многие браузеры навязывают эту политику одного и того же происхождения.
Теперь, когда мы говорим об одном происхождении, как мы можем указать происхождение?
Теперь в этом контексте источник для любого ресурса определяется тремя кортежами.
Во-первых, протокол, используемый для доступа к ресурсу.
Во-вторых, имя хоста ресурса или домен этого ресурса.
И в-третьих, номер порта, с которого осуществляется доступ к этому ресурсу.
Так мы определяем происхождение любого ресурса.
Ресурсом в этом случае может быть html-страница, изображение,
данные JSON, получаемые из конечной точки REST API, и многое другое.
Чтобы подробнее остановиться на политике одного происхождения, давайте рассмотрим пример.
Предположим, что у нас есть веб-страница, которая загружается с этого сайта, перечисленных здесь
, www.abc.com, и в папке xyz, и
page.html загружается здесь.
Эта страница может включать ссылки или даже код JavaScript, который может
выдавать XMLHttpRequest другим ресурсам на веб-странице.
Теперь, в этом случае, если мы попытаемся получить доступ к другому URL,
например, первый из перечисленных здесь, который, очевидно, вы видите
из того же сайта, но из другой папки.
Это приемлемо, поскольку источник, в данном случае
используемый протокол и номер порта, остается прежним.
Таким образом, это приемлемо для доступа к этому ресурсу.
Аналогично во втором случае, мы можем иметь под
несколько уровней подпапок ресурс, к которому обращаются.
Но опять же, поскольку их происхождение остается прежним, что приемлемо.
Но давайте посмотрим на третий пример здесь.
В этом примере мы видим, что мы пытаемся получить доступ к ресурсу здесь с
протоколом https, который, очевидно, нарушает принцип
того же происхождения, потому что мы используем другой протокол для доступа к этому ресурсу в данный момент.
Так что в данном случае это будет считаться неудачей.
Четвертый случай - это когда мы обращаемся к ресурсу с другим номером порта.
И пятый случай, когда мы получаем доступ к ресурсу на другом хосте.
Теперь все эти три будут помечены как недействительные или не
могут быть доступны в рамках этой политики одного и того же происхождения.
Поэтому, если вы навязываете политику одного происхождения для доступа, например, из
вашего XMLHttpRequest, последние три не будут разрешены в этом случае.
Но, конечно, есть много ситуаций, когда этот дизайнер сайта
может фактически размещать ресурсы на разных сайтах, возможно, на разных доменах,
и все равно иметь возможность вытаскивать данные,
чтобы построить веб-страницу или запустить веб-приложение или запустить гибридное мобильное приложение .
Таким образом, чтобы учесть эти ситуации,
обработка запросов с перекрестным происхождением является метод, который позволяет нам получить доступ к этим ресурсам.
Поэтому мы рассматриваем запрос как
запрос с перекрестным происхождением, если вы пытаетесь получить доступ к ресурсу из другого домена
или с другим номером порта, или с другим протоколом.
Итак, как мы можем учитывать ситуации, когда это законный доступ к ресурсу,
но из-за политики того же происхождения
ваш браузер откажется загружать этот ресурс?
Теперь, как я уже упоминал,
многие браузеры будут ограничивать HTTP-запросы с перекрестным происхождением,
особенно те, которые инициируются
XMLHttpRequest или протоколом Fetch для извлечения данных.
Они актуальны, когда мы обращаемся к ним из нашего кода JavaScript.
Таким образом, в таких обстоятельствах имеет смысл навязывать политику одного происхождения,
но тогда мы должны иметь способ обойти ситуацию, когда
может быть выдан законный запрос.
Именно здесь нам на
помощь приходит подход CORS, основанный на совместном использовании ресурсов из разных источников.
Таким образом, этот CORS является механизмом, который позволяет веб-серверам выполнять
междоменные запросы или запросы перекрестного происхождения.
Поэтому здесь браузер и сервер,
откуда вы пытаетесь исправить ресурс, будут взаимодействовать друг с другом, а
затем прийти к соглашению, заявив, что этот доступ является приемлемым и разрешенным.
Таким образом, как только соглашение будет достигнуто,
то этот запрос может быть разрешен вашим браузером.
Таким образом, браузер и сервер будут взаимодействовать друг с другом, чтобы
определить, является ли этот доступ к этому ресурсу приемлемой ситуацией.
Таким образом, здесь новый набор HTTP-заголовков был
введен в сообщения ответа HTTP, поступающие со стороны сервера.
Эти заголовки позволяют серверам описывать набор источников
, разрешенных сервером для доступа браузера.
И, в свою очередь, браузер понимает, что доступ к ресурсам
допустим, даже если они нарушают эту
политику того же происхождения, которую мы видели ранее.
Таким образом, в этом случае у нас есть заголовки, такие как, например,
Access-Control-Allow-Origin,
Access-Control-Allow-Credentials, Access-Control-Allow-Headers, Access-Control-Allow-Methods и
несколько других, которые сервер использует для информирования браузера, говоря, что
это приемлемый способ доступа ресурс со стороны браузера.
И когда браузер видит эти входящие ответные сообщения со стороны сервера,
браузер принимает и позволяет выполнить этот запрос перекрестного происхождения.
Теперь это также означает, что сервер должен быть настроен, чтобы иметь возможность
отвечать с этими полями заголовка и
информацией заголовка, включенной в ответное сообщение, поступающее со стороны сервера.
Теперь, здесь мы делим все запросы перекрестного происхождения на
несколько категорий.
У нас есть первый простой межсайтовый запрос.
В простых межсайтовых запросах вы можете использовать GET или
POST с телом запроса.
Но когда вы используете POST, ваше тело запроса должно содержать
либо application/x-WWW-Urlencoded,
либо multipart/form-data, либо text/plain.
Затем он рассматривается как простой межсайтовый запрос, и
в этом случае пользовательские заголовки не будут разрешены.
Таким образом, в этом случае сервер может сообщить клиенту,
заявив, что это разрешено, и браузер должен разрешить такие запросы.
Так, например, для широко доступных ресурсов, например,
если вы выполняете запрос GET на сервер, чтобы получить данные для
создания пользовательского интерфейса, тогда, возможно, запрос GET является приемлемым
независимо от того, из какого источника исходит этот запрос.
Таким образом, в этом случае ваш сервер ответит клиенту,
сказав Access-Conrol-Allow-Origin, с этой звездочкой подстановок здесь,
что означает, что любое происхождение, которое создает запрос, приемлемо, и
браузер должен разрешить выполнение запроса на этот сервер.
И теперь вы также можете ограничить доступ к источнику.
В этом случае можно конкретно сказать, что если источником является
конкретный сайт, то приемлемо обслуживать этот запрос.
Таким образом, браузер видит, что отправка запросов
с этим конкретным исходным сайтом в запросе приемлема, и
мы разрешим запрос перекрестного происхождения.
Таким образом, вы можете контролировать способ происхождения
указан в сообщении запроса, поступающем со стороны клиента.
Таким образом, сервер может принимать такие запросы.
Некоторые другие запросы будут подпадать под категорию предварительных запросов.
В предполетном запросе вы ожидаете, что перед отправкой клиентом
фактического запроса клиент отправит предпечатный запрос,
что означает, что он связывается с сервером для получения
информации от сервера до того, как будет выдан фактический запрос.
Это особенно случай, когда вы выдаете запросы PUT и DELETE,
потому что запросы PUT и DELETE могут вызвать изменения на стороне сервера.
И поэтому любой метод, который вызывает побочные эффекты на данных сервера, например
запрос PUT и DELETE, специально уполномочен следовать предполетному подходу.
В предпечатном подходе идея заключается в том, что клиент
сначала отправит запрос HTTP OPTIONS на стороне сервера, и
в ответ на это сообщение запроса OPTIONS со стороны клиента, сервер будет
отвечать соответствующим Access-Control-Allow-Headers,
Access-Control-Allow-Origin, и
информация заголовка Access-Control-Allow-Credentials в ответе на сообщение OPTIONS.
После этого клиент решит, может ли он выдать запрос перекрестного происхождения или
нет, основываясь на ответе на предпечатный запрос OPTIONS, отправленный клиентом.
Таким образом, здесь вам нужно пройти два шага, прежде чем ваш запрос
может быть разрешен и обслужин на стороне сервера.
Третьей категорией запросов CORS будет то, что называется проверенными запросами,
где вы ожидаете, что клиент будет включать учетные данные в заголовок
сообщения запроса.
Таким образом, запросы, которые сопровождаются куки, например, для
распознавания сеанса на стороне сервера, или какая-то HTTP-аутентификация
информации в заголовке авторизации в сообщении запроса.
Таким образом, в этом случае сервер должен ответить с помощью
Access-Control-Allow-Credentials: true на стороне клиента.
Таким образом, в этом случае сервер ответит этим, а
затем клиенту будет разрешено отправлять
информацию о своих учетных данных во входящем запросе со стороны клиента.
Теперь, в этом случае, Access-Control-Allow-Origin не разрешается
иметь в ответном сообщении символ-символ.
Ожидается, что явное указание источника, к
которому может быть инициирован запрос.
Теперь, очевидно, мы можем реализовать большую часть работы,
что нам нужно сделать на стороне сервера, реализуя наше собственное промежуточное программное обеспечение, если мы так
решили обрабатывать ответы, связанные с CORS со стороны сервера.
Это очень просто, как мы видели в коде, который мы реализовали.
Конечно, это один из способов обработки ответов, связанных с CORS со стороны сервера,
но, к счастью, у нас есть конкретный CORS NodemoDule,
который предназначен для обработки этой самой
работы, которую сервер должен выполнить для удовлетворения требований CORS.
Таким образом, CORS NodemoDule позволяет нам настроить CORS на стороне сервера, в
том числе указать информацию о происхождении, где будут приняты учетные данные,
и многие другие сведения, так что вы можете настроить сервер,
чтобы иметь возможность обрабатывать ответы, связанные с CORS, которые он должен дать
в браузер в ответ на сообщение запроса.
Чтобы установить CORS NodemoDule, очевидно, вы видите npm install cors,
а затем настроить промежуточное программное обеспечение CORS в вашем экспресс-приложении.
Сам модуль CORS обеспечивает очень простой способ включения CORS.
Вы можете просто включить использование приложения CORS с пустыми скобками, и
это по существу означает, что вы открываете свой сервер, и он будет отвечать с помощью
Access-Control-Allow-Origin со звездой Wild карты на каждый входящий запрос.
Но когда вы настраиваете свой сервер, вы можете захотеть больше контроля над этим, так
что здесь мы можем указать дополнительные параметры для CORS.
И не только это, вы можете навязать обработку CORS
по-разному для разных маршрутов на стороне вашего сервера.
Таким образом, как мы увидим в упражнении, мы будем накладывать различные требования CORS
на разных маршрутах на нашей стороне сервера, и все это настраивается с помощью
различных параметров конфигурации, которые CORS NodemoDule поддерживает для нас.
Таким образом, используя CORS NodemoDule, очень легко настроить ваш сервер для обработки
любых запросов перекрестного происхождения, поступающих с вашей клиентской стороны, а
затем отвечать с соответствующей информацией заголовка на стороне клиента
с соответствующими заголовками CORS в ответном сообщении со стороны сервера.
С этим быстрым пониманием CORS,
я уверен, что у вас на данный момент больше вопросов, чем ответов из этой лекции.
Но если вы хотите прочитать гораздо больше информации о CORS,
я предоставил вам дополнительные ресурсы в конце этого урока,
которые позволят вам узнать больше о самой CORS.
Но с точки зрения этого курса, мы хотели бы настроить наше
экспресс-приложение, которое мы разрабатываем
до сих пор для обработки вопросов, связанных с CORS на стороне сервера.
Таким образом, перейдя к упражнению, мы установим модуль CORS npm, а
затем настроим его на различных маршрутах внутри нашего дополнительного сервера.
[ МУЗЫКА]