Как настроить cors node js

Как настроить cors node js

CORS is a node.js package for providing a Connect/Express middleware that can be used to enable CORS with various options.

This is a Node.js module available through the npm registry. Installation is done using the npm install command:

Simple Usage (Enable All CORS Requests)

Enable CORS for a Single Route

Configuring CORS w/ Dynamic Origin

If you do not want to block REST tools or server-to-server requests, add a !origin check in the origin function like so:

Enabling CORS Pre-Flight

Certain CORS requests are considered ‘complex’ and require an initial OPTIONS request (called the «pre-flight request»). An example of a ‘complex’ CORS request is one that uses an HTTP verb other than GET/HEAD/POST (such as DELETE) or that uses custom headers. To enable pre-flighting, you must add a new OPTIONS handler for the route you want to support:

You can also enable pre-flight across-the-board like so:

Configuring CORS Asynchronously

• origin : Configures the Access-Control-Allow-Origin CORS header. Possible values:
  • Boolean — set origin to true to reflect the request origin, as defined by req.header(‘Origin’) , or set it to false to disable CORS.
  • String — set origin to a specific origin. For example if you set it to «http://example.com» only requests from «http://example.com» will be allowed.
  • RegExp — set origin to a regular expression pattern which will be used to test the request origin. If it’s a match, the request origin will be reflected. For example the pattern /example\.com$/ will reflect any request that is coming from an origin ending with «example.com».
  • Array — set origin to an array of valid origins. Each origin can be a String or a RegExp . For example [«http://example1.com», /\.example2\.com$/] will accept any request from «http://example1.com» or from a subdomain of «example2.com».
  • Function — set origin to a function implementing some custom logic. The function takes the request origin as the first parameter and a callback (which expects the signature err [object], allow [bool] ) as the second.
• methods : Configures the Access-Control-Allow-Methods CORS header. Expects a comma-delimited string (ex: ‘GET,PUT,POST’) or an array (ex: [‘GET’, ‘PUT’, ‘POST’] ).
• allowedHeaders : Configures the Access-Control-Allow-Headers CORS header. Expects a comma-delimited string (ex: ‘Content-Type,Authorization’) or an array (ex: [‘Content-Type’, ‘Authorization’] ). If not specified, defaults to reflecting the headers specified in the request’s Access-Control-Request-Headers header.
• exposedHeaders : Configures the Access-Control-Expose-Headers CORS header. Expects a comma-delimited string (ex: ‘Content-Range,X-Content-Range’) or an array (ex: [‘Content-Range’, ‘X-Content-Range’] ). If not specified, no custom headers are exposed.
• credentials : Configures the Access-Control-Allow-Credentials CORS header. Set to true to pass the header, otherwise it is omitted.
• maxAge : Configures the Access-Control-Max-Age CORS header. Set to an integer to pass the header, otherwise it is omitted.
• preflightContinue : Pass the CORS preflight response to the next handler.
• optionsSuccessStatus : Provides a status code to use for successful OPTIONS requests, since some legacy browsers (IE11, various SmartTVs) choke on 204 .

The default configuration is the equivalent of:

For details on the effect of each CORS header, read this article on HTML5 Rocks.

Источник

Политика общего происхождения и CORS: визуальное руководство

Доброго времени суток, друзья!

Представляю вашему вниманию перевод статьи «CS Visualized: CORS» автора Lydia Hallie.

Каждому разработчику приходилось сталкиваться с ошибкой Access to fetched has been blocked by CORS policy . Существует несколько способов быстрого решения данной проблемы. Однако, давайте не будем спешить и подробно рассмотрим, что из себя представляет политика CORS.

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

Допустим, мы хотим получить информацию о пользователе на нашем сайте www.mywebsite.com с сервера, расположенного на сайте api.website.com .

Отлично! Мы только что отправили запрос на сервер и получили в ответ данные в формате JSON.

Теперь попробуем отправить аналогичный запрос на другой домен. Вместо того, чтобы отправлять запрос с www.mywebsite.com , отправим его с www.anotherdomain.com .

Что случилось? Мы отправили точно такой же запрос, но на этот раз браузер показывает какую-то ошибку.

Мы наблюдаем CORS в действии. Почему возникла данная ошибка и что она означает?

Политика общего происхождения

В вебе присутствует нечто под названием политика общего происхождения (далее — ПОП). По умолчанию мы имеем доступ только к тем ресурсам, которые находятся в том же источнике, что и источник нашего запроса. Например, мы можем загрузить изображение, находящееся в https://mywebsite.com/image1.png .

Источник является другим, когда он расположен в другом (под)домене, протоколе или порте.

Круто, но зачем нужна ПОП?

Предположим, что ее не существует, и вы случайно кликаете по вирусной ссылке, которую прислала ваша тетя в Facebook. Данная ссылка перенаправляет вас на «вредоносный сайт», имеющий встроенный iframe, который загружает сайт вашего банка и успешно авторизуется там с помощью куки.

Разработчики «злого сайта» позаботились о том, чтобы он имел доступ к iframe и мог взаимодействовать с содержимым DOM сайта вашего банка для перечисления денежных средств на свой аккаунт от вашего имени.

Да уж… это серьезная проблема безопасности. Мы не хотим, чтобы кто-нибудь имел доступ к чему-либо без нашего ведома.

К счастью, существует ПОП. Эта политика ограничивает доступ к ресурсам из других источников.

В данном случае источник www.evilwebsite.com пытается получить доступ к ресурсу из источника www.bank.com . ПОП блокирует такой доступ и запрещает разработчикам «плохого сайта» доступ к вашим банковским данным.

Хорошо, но… как это работает?

CORS на стороне клиента

Несмотря на то, что ПОП применяется только к скриптам, браузеры «расширяют» ее до любых JavaScript-запросов: по умолчанию мы имеем доступ только к ресурсам из одного источника.

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

CORS расшифровывается как Cross-Origin Resource Sharing (совместное использование ресурсов). Хотя браузеры запрещают получение ресурсов из других источников, мы можем использовать CORS для изменения этого ограничения, оставаясь при этом в безопасности.

Пользовательские агенты (браузеры) могут использовать механизм CORS для разрешения запросов между разными источниками, которые в противном случае были бы заблокированы, на основе некоторых заголовков HTTP-ответа.

Когда происходит запрос к другому источнику, клиент автоматически добавляет в HTTP-запрос заголовок Origin . Значением этого заголовка является источник запроса.

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

CORS на стороне сервера

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

Существует несколько CORS-заголовков, но один из них является обязательным: Access-Control-Allow-Origin .

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

Если мы разрабатываем сервер, который должен быть доступен https://mywebsite.com , мы должны добавить этот домен в заголовок Access-Control-Allow-Origin .

Здорово. Данный заголовок теперь добавляется к ответу сервера, отправляемого клиенту. ПОП больше не запрещает нам получать ресурсы с https://api.mywebsite.com с помощью запросов, отправленных с https://mywebsite.com .

Механизм CORS, реализованный в браузере, проверяет совпадение значений заголовка ответа Access-Control-Allow-Origin и заголовка запроса Origin .

В данном случае источником нашего запроса является https://www.mywebsite.com , указанный в списке заголовка ответа Access-Control-Allow-Origin .

Отлично. Теперь мы можем получать ресурсы из других источников. Что произойдет, если мы попытаемся сделать это из источника, не указанного в Access-Control-Allow-Origin ?

Да, CORS заблокировал доступ к ресурсам.

В данном случае источником является https://www.anotherwebsite.com , не указанный в Access-Control-Allow-Origin . CORS успешно запретил получение запрашиваемых данных.

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

Access-Control-Allow-Origin — это один из многих заголовков, которые мы можем установить. Разработчик серверной части может настраивать CORS для разрешения (запрета) конкретных запросов.

Другим распространенным заголовком является Access-Control-Allow-Methods . CORS разрешает только те запросы из других источников, которые были отправлены с помощью указанных методов.

В данном случае разрешены только запросы, отправленные с помощью методов GET, POST или PUT. Другие методы, такие как PATCH или DELETE будут заблокированы.

Говоря о запросах, отправленных с помощью методов PUT, PATCH и DELETE, CORS обрабатывает их особым образом. Эти «непростые» запросы иногда называют предварительными (preflight).

Предварительные запросы

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

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

Хорошо, но что означает предварительный запрос и зачем нужны такие запросы?

Перед отправкой фактического запроса, клиент направляет серверу предварительный запрос с информацией о фактическом запросе: о его методе, дополнительных заголовках, включая Access-Control-Request-* и т.д.

Сервер получает предварительный запрос и отправляет пустой предварительный ответ, содержащий CORS-заголовки. Браузер получает предварительный ответ и проверяет, будет ли разрешен фактический запрос.

Если да, то браузер отправляет фактический запрос и получает данные в ответ.

Если нет, CORS заблокирует предварительный запрос и фактический запрос не будет отправлен. Предварительные запросы — это отличный способ предотвратить доступ и изменение ресурсов на сервере. Это защищает сервер от потенциально нежелательных запросов из других источников.

Для уменьшения количества повторных запросов мы можем закэшировать предварительный ответ посредством добавления заголовка Access-Control-Max-Age в CORS-запрос. Это позволяет избежать повторного направления предварительного запроса.

Полномочия (credentials)

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

Хотя CORS не содержит полномочий по умолчанию, мы можем изменить это с помощью заголовка Access-Control-Allow-Credentials .

Если мы хотим включить куки и другие заголовки авторизации в наш запрос из другого источника, нам нужно присвоить полю withCredentials значение true в запросе и добавить заголовок Access-Control-Allow-Credentials в ответ.

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

Надеюсь, статья была вам полезной. Благодарю за внимание.

Источник

Обработка CORS в Express

Как разрешить межсайтовые запросы, настроив CORS

Приложение JavaScript, запущенное в браузере, обычно может получить доступ к ресурсам HTTP только из того же домена (источника), который их обслуживает.

Загрузка изображений или скриптов / стилей из одного источника всегда работает. Кроме того, загрузка веб-шрифтов с помощью @font-face по умолчанию установлена политика «одинакового происхождения». То же самое и с другими, менее популярными вещами (такими как текстуры WebGL и drawImage ресурсы, загруженные в Canvas API).

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

Этот механизм называетсяCORS,Совместное использование ресурсов между источниками.

Одна очень важная вещь, которая требует CORS, — этоМодули ES, недавно представленный в современных браузерах.

Если вы не настроили политику CORSна серверечто позволяет ему обслуживать сторонние источники, запрос не будет выполнен.

Ресурс Cross-Origin не работает, если он:

• к другомудомен
• к другомусубдомен
• к другомупорт
• к другомупротокол

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

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

Это зависит от вашего серверного стека.

Поддержка браузера

Довольно неплохо (в основном все, кроме IE /without-cors с запросом на выборку из другого источника, это поднимет проблему CORS.

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

Обратите внимание на то, что запрос, который не выполняется из-за того, что сервер неправильно обрабатывает заголовки CORS, все еще принимается. Как вы можете видеть на панели Network, где вы можете увидеть сообщение, отправленное сервером:

Разрешить только определенное происхождение

Однако в этом примере есть проблема: ЛЮБОЙ запрос будет принят сервером как кросс-источник.

Как вы можете видеть на панели «Сеть», у прошедшего запроса есть заголовок ответа. access-control-allow-origin: * :

Вам необходимо настроить сервер, чтобы разрешить обслуживание только одного источника и заблокировать все остальные.

Используя тот же cors Библиотека узлов, вот как вы это сделаете:

Вы также можете подавать больше:

Предполетный

Есть некоторые запросы, которые обрабатываются «просто». Все GET запросы принадлежат к этой группе.

Такженемного POST и HEAD запросы тоже.

POST запросы также входят в эту группу, если они удовлетворяют требованию использования Content-Type

• application/x-www-form-urlencoded
• multipart/form-data
• text/plain

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

Предварительный запрос содержит несколько заголовков, которые сервер будет использовать для проверки разрешений (нерелевантные поля опущены):

Источник