Что хуже всего после IE?
CORS (совместное использование ресурсов между источниками)
Давайте сразу перейдем к делу, на мой взгляд, CORS ужасен. Это реализация на основе клиента, которая, кажется, создает больше проблем для разработчиков, чем приносит пользу.
Пользователь может легко переключиться на клиента, который не поддерживает поведение CORS, мгновенно обойдя все, что пытается достичь CORS.
И да, это еще один пост, в котором не нравится CORS. Но это потому, что, как и Internet Explorer, CORS вызовет головную боль разработки, на исправление которой могут потребоваться часы (возможно, даже недели при использовании поставщика облачного хостинга) в течение многих лет.
Что такое CORS?
CORS предназначен для ограничения доступа к ресурсам, которые вы контролируете, путем определения доменов и субдоменов, которые могут получить доступ к этим ресурсам. Клиенты, пытающиеся получить доступ к этим ресурсам из другого домена (источника), могут быть заблокированы от доступа к ресурсам на основе заголовков CORS, установленных в удаленном ресурсе.
Вы можете узнать больше о CORS здесь:
CORS - плохое решение "безопасности"
Если кто-то действительно хочет получить доступ к ресурсу, но заблокирован CORS, скорее всего, он может просто посетить URL-адрес напрямую или использовать другого клиента, который не использует CORS (например, Curl).
Многие браузеры следуют заголовкам CORS и не будут включать на веб-страницу какие-либо ресурсы, заблокированные CORS, но это можно отключить. Точно так же знаки могут просить вас вежливо следовать правилу, но сам знак не может обеспечить соблюдение правила.
Знак «Вход запрещен» или «Пожалуйста, оставайтесь на пути» не мешает вам делать эти вещи, но, к счастью, большинство людей склонны следовать правилам подписать. Заборы, стены и охрана, вероятно, не позволят вам пройти мимо знака «Въезд запрещен» (если вы не совсем настроены). Добавление серверных проверок к запросам будет работать аналогичным образом, разрешая доступ только к определенным доменам, но есть проблема, эти заголовки запросов и данные о происхождении по-прежнему могут быть подделаны.
В большинстве мест, где я контактировал с CORS, заголовки обычно просто устанавливались для всего, чтобы либо разрешить доступ везде, либо разрешить доступ только к одному домену. Чтобы сделать что-либо еще, потребуется спланировать, какие домены / поддомены должны получать доступ к ресурсам, и поддерживать их в актуальном состоянии с течением времени. Если мы постоянно настраиваем доступ ко всему, зачем вообще беспокоиться о CORS?
Знак «Въезд запрещен» вам все равно не помешает.
Работа с CORS тратит время
Количество времени, потраченного впустую из-за CORS, должно быть огромным. Я не удивлюсь, если разработчики потратят больше времени на устранение проблем с CORS, чем они потратили на реализацию самой CORS.
Во многом так же, как в течение многих лет разработчики исправляли специфические проблемы IE. К счастью, теперь у людей есть больший выбор браузеров, и ИТ-администраторы меньше вынуждены использовать устаревший браузер по умолчанию (Internet Explorer).
Многие веб-сайты по-прежнему работают на старых базах кода, в которых отсутствует поддержка CORS, и самое простое «исправление» при работе с этими старыми базами кода - добавить заголовки ответов CORS, которые разрешают доступ ко всему. Это неправильный способ делать что-то, но в большинстве случаев разработчики вынуждены завершить исправление ошибки / функцию в течение определенного периода времени, и поэтому у них нет времени для расчета и установки заголовков CORS. Итак, чтобы предотвратить нарушение каких-либо существующих частей сайта, разработчики просто разрешат доступ ко всему.
Что нам действительно нужно, так это больше времени на разработку, чтобы мы могли устанавливать и поддерживать CORS, устанавливая правильные правила того, где наши ресурсы могут / не могут быть включены.
Считаете ли вы, что разработка CORS тратит время? Вы нашли CORS полезным в каких-либо проектах?
