Каждый веб-разработчик в какой-то момент сталкивается с проблемой CORS при разработке веб-сайта. CORS описан в документации MDN как:

«Совместное использование ресурсов между источниками (CORS)» - это механизм на основе HTTP-заголовка, который позволяет серверу указывать любые другие источники (домен, схема или порт), кроме своего собственного, из которых браузер должен разрешать загрузку ресурсов. CORS также полагается на механизм, с помощью которого браузеры отправляют «предварительный» запрос на сервер, на котором размещен ресурс из разных источников, чтобы проверить, разрешит ли сервер фактический запрос. В этой предварительной проверке браузер отправляет заголовки, которые указывают метод HTTP и заголовки, которые будут использоваться в фактическом запросе ».

CORS aka. Совместное использование ресурсов Cross Origin - это механизм, который означает, что веб-сайт с одного URL-адреса запрашивает данные с другого URL-адреса, и это расстраивает как интерфейс, так и серверную часть, потому что обречено на это.

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

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

Так что постарайтесь понять простым языком.

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

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

Access-Control-Allow-Origin:foo.com

Это самая частая проблема. Это происходит из соображений безопасности браузером. Один из способов решить этот общий метод - добавить подстановочный знак * в бэкэнд, чтобы любой URL-адрес запроса мог совместно использовать ресурс, но это переводит ваш сервер в более опасный режим, который может подвергнуться хакерской атаке.

Не волнуйтесь, у нас есть подходящий способ решить эту проблему.

Как решить эту проблему

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

Настроить CORS с параметрами

Вы также можете использовать параметры конфигурации с CORS для дальнейшей настройки.

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

const express = require('express');
const cors = require('cors'); 
const app = express(); 

var corsOptions = {
   origin: ‘http://localhost:8080', 
   optionsSuccessStatus: 200 // For legacy browser support
}
app.use(cors(corsOptions));
app.get('/', (req, res) => { 
  res.json({ 
    message: 'Hello World' 
  }); 
});
app.listen(2020, () => { 
   console.log('server is listening on port 2020'); 
});

Вы также можете настроить разрешенные методы HTTP, если хотите

var corsOptions = {    
    origin: 'http://localhost:8080',    
    optionsSuccessStatus: 200 // For legacy browser support                
    methods: "GET, PUT" 
}  
app.use(cors(corsOptions));

Эта строка кода добавит заголовки источника во все HTTP-ответы.

Нестандартные заголовки предпечатной проверки

Теперь определенные HTTP-методы, такие как PUT, DELETE, PATCH, которые являются нестандартными заголовками, должны быть предпечатными. Это похоже на проверку состояния здоровья пассажира в аэропорту, чтобы убедиться, что теперь пассажир полностью проверен перед взлетом.

Таким же образом для этих HTTP-методов браузер знает, когда выполнять предполетную проверку с помощью HTTP-команды под названием OPTION, и в ответ сервер будет 204 как да, я разрешаю этому источнику делать HTTP-запрос, но делаю это со следующими методами . Смысл всего этого в том, чтобы обеспечить выполнение основного запроса без каких-либо сбоев.

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

По-прежнему сталкиваетесь с проблемами CORS?

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

Причина 1. Откройте вкладку сети и проверьте Allow-Control-Allow-Origin, если он не отображается, вам необходимо включить CORS на сервере.

Причина 2: если он существует, возможно, URL-адрес не соответствует URL-адресу запроса и ответу Allow-Control-Allow-Origin, в качестве альтернативы вы можете добавить подстановочный знак *, чтобы разрешить все URL-адреса запросов.

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

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

Продолжайте кодировать, спасибо за чтение этого блога.