Что, черт возьми, такое ошибка CORS?

Я имею в виду, ничего веселого. Это данность.

В программировании есть только две уверенности: ошибки и, в конечном итоге, ошибка CORS.

Столкновение с самой первой ошибкой CORS, похоже, является обрядом в мире разработки. Натыкаясь на ванильный JavaScript и попадая в причудливый мир React.js, Node.js, Angular и нескольких других языков, построенных на основах, представленных в простом JS, многие начинающие разработчики столкнутся с этим хитрым маленьким гоблином. в первый раз -

И они плачут.

В смысле, я хотел.

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

Анализ этих надоедливых писем

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

Первый вверх:

Происхождение

Представьте, если хотите, скромный URL. Его состав довольно прост. Впереди обычно указывается его схема (либо HTTP, либо HTTPS), его имя хоста (домен и любой поддомен, прикрепленный к нему) и его порт. По умолчанию проценты обычно равны 80 — поэтому они часто не отображаются в URL-адресах для большинства сайтов. Вы видите порты при локальной разработке, например, когда вы видите localhost:8080 на своем собственном устройстве.

Однако что означает, что два URL-адреса имеют одно и то же происхождение? По сути, это просто означает, что они разделяют все эти вещи — свою схему, имя хоста (и прикрепленные субдомены) и порты. Например, https://www.medium.com/p/3443555 и https://www.medium.com/p/4643543 имеют одно и то же происхождение, поскольку используют одну и ту же схему (https), одинаковую имя хоста (www.medium.com) и тот же порт (невидимый порт 80). Что включено после происхождения — разные пути — не имеет значения. Эти два веб-сайта имеют одинаковое происхождение.

Но что значит иметь другое происхождение? Хорошо, если что-то из этого отличается. Если бы одна версия среды использовала схему http, а не схему https, источники были бы другими. Даже если их доменные имена и порты останутся прежними, их происхождение будет другим; это верно, если какая-либо из этих отдельных вещей обменивается и отличается от URL-адреса, который мы пытаемся удерживать параллельно. Это также относится к локальным серверам, таким как http://localhost:3000 и http://localhost:4000. Из-за смены порта они не имеют одинакового происхождения.

Ресурс

«Ресурс» — чрезвычайно широкий термин, который относится практически ко всему, что вы можете запросить с сервера. JSON, HTML, изображение — все это подпадает под понятие «ресурс». Когда запрос отправляется со стороны клиента на URL-адрес (в случае моего кода я запрашивал JSON из внешнего API), вы обычно возвращаете то, что вы просили, и все, что вы просили, это почти всегда можно назвать «ресурсом».

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

Но браузеры. Дорогие, милые браузеры.

Они топят корабль.

Браузеры

Браузеры содержат в себе функцию, которая называется «Единая политика происхождения». «Политика того же происхождения» означает, что при использовании выборки (также известной как отправка запроса на некоторые ресурсы) вам разрешено делать запросы только к тому же источнику, что и страница, через которую вы направляете запрос. Эта выборка больше похожа на XMLHttpRequest. Если источник не одинаков между обеими этими сторонами — URL-адрес, отправляющий запрос, и URL-адрес, получающий его — браузер включится и откажет в обмене, помимо встроенных мер безопасности, и, таким образом, вместо этого вы получите вернуться к ошибке CORS.

Почему браузеры это делают? Ну, это в основном ради тех, кто взаимодействует с клиентской стороной. Запрещая такое поведение, браузеры помогают в конечном итоге обеспечить безопасность своих пользователей. В противном случае сотни тысяч людей могли бы непреднамеренно нажать на мошеннические ссылки, которые содержат что-то вроде HTTP-запроса, который маскируется под что-то другое и вместо этого представляет собой пакет кода JS, который отправляет запрос на выборку, скажем, Twitter.com. Даже если отправка запроса с вашей стороны была непреднамеренной — в конце концов, вы только открыли URL-адрес — запрос на выборку будет поступать с вашего компьютера, и, таким образом, человек, ответственный за мошеннический файл, получит информацию о вашем сеансе. При этом они могут делать множество вещей: одна из наиболее очевидных в этом контексте — это то, что они могут затем отправить другую выборку, используя полученную информацию, на свой собственный сервер, а затем использовать ее для доступа к вашей учетной записи Twitter. Это можно сделать на нескольких платформах, в том числе с более высокими ставками, таких как финансовые учреждения, хранилища и т. д.

Всемогущий CORS предотвращает все это. Запросы JavaScript к информации из других источников запрещены, если сервер в этом другом источнике явно не разрешил это. Как правило, это делается на внутренней стороне; клиентская сторона никогда не сможет исправить ошибки CORS от своего имени. Вместо этого это обрабатывается различными способами в серверной части большинства веб-сайтов; некоторые разработчики используют прокси-серверы в качестве изящной точки встречи между двумя серверами с разным происхождением, некоторые специально жестко кодируют их в ресурс, который они намереваются использовать совместно. Последнее можно сделать, включив в свой ответ заголовок под названием «Access-Control-Allow Origin», который можно использовать для указания других источников, которым разрешено запрашивать определенный ресурс, которым они владеют.

Ну, как мне это исправить?

Я хотел бы, чтобы я мог сказать вам. Как начинающий разработчик, я все еще настраиваю, как именно обрабатывать ошибки CORS, с которыми я сталкиваюсь. Простое клиентское решение — установить в браузере расширение, которое аннулирует SOP и разрешает CORS. Более сложным путем будет управление любым API или ресурсом, которые вы получаете через серверную часть, возможно, с помощью библиотеки, такой как Node.js. Если вы столкнулись с ошибкой CORS при попытке запроса из API, вполне вероятно, что API изначально не поддерживает CORS, поэтому вместо этого его нужно будет вызывать из-за пределов браузера, чтобы не столкнуться с ужасной SOP. Прокси-сервер можно настроить с помощью Node и используемых там ресурсов/библиотек. Затем прокси-сервер может быть вызван из вашего внешнего интерфейса.

Есть несколько других способов смягчить все это. В настоящее время они находятся за пределами моей компетенции.

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