Каждый веб-разработчик в какой-то момент сталкивается с проблемой 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, и вы можете решить все это с помощью указанного метода упоминания.
Продолжайте кодировать, спасибо за чтение этого блога.