Кажется, предварительная проверка для CORS не имеет смысла. Это шутка?

Согласно примерам из здесь:

Если в запросе используются методы, отличные от GET, HEAD или POST. Кроме того, если POST используется для отправки данных запроса с Content-Type, отличным от application/x-www-form-urlencoded, multipart/form-data или text/plain, например. если запрос POST отправляет полезные данные в формате XML на сервер с использованием application/xml или text/xml, то запрос считается предварительно проверенным.

Итак, в следующем примере предварительная проверка выполняется из-за XML Content-Type и пользовательского заголовка X-PINGOTHER:

var invocation = new XMLHttpRequest();
var url = 'http://bar.other/resources/post-here/';
var body = '<?xml version="1.0"?><person><name>Arun</name></person>';

function callOtherDomain(){
  if(invocation)
    {
      invocation.open('POST', url, true);
      invocation.setRequestHeader('X-PINGOTHER', 'pingpong'); //<====
      invocation.setRequestHeader('Content-Type', 'application/xml'); //<====
      invocation.onreadystatechange = handler;
      invocation.send(body); 
    }
}

Но в так называемом предварительном запросе OPTIONS (ниже) сервер уведомляется только о методе HTTP и пользовательском заголовке. Никто не сообщил серверу о XML Content-Type.

Логически, если запрос на предварительную проверку отправлен, это подразумевает, что Content-Type не входит в 3 формы, которые не требуют предварительной проверки. Но может быть множество других возможностей. Суть в том, что сервер должен знать, почему отправляется предварительный запрос.

Итак, как сервер может разумно решить, разрешать ли этот запрос с отсутствующей частью головоломки (тип контента)?

введите здесь описание изображения


cors preflight
person smwikipedia    schedule 07.01.2016    source источник
comment
Если возможно, пожалуйста, поместите свой код в виде текста, а не в виде изображений.   -  person toasted_flakes    schedule 07.01.2016
comment
@toasted_flakes Хорошо, исправлено.   -  person smwikipedia    schedule 07.01.2016

Ответы (1)


arrow_upward
3
arrow_downward

CORS почти всегда безопасен. Цитата из стандарта Fetch,

Для ресурсов, где данные защищены с помощью IP-аутентификации или брандмауэра (к сожалению, все еще довольно распространенного), использование протокола CORS небезопасно. (Вот почему пришлось изобрести протокол CORS.)

Однако в противном случае использование следующего заголовка безопасно:

Доступ-Контроль-Разрешить-Происхождение: *

Даже если ресурс предоставляет дополнительную информацию на основе файлов cookie или HTTP-аутентификации, использование приведенного выше заголовка не раскроет ее. Он будет делиться ресурсом с такими API, как XMLHttpRequest, так же, как он уже используется совместно с curl и wget.

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

Таким образом, серверу не нужно ничего знать о типе контента запроса, чтобы знать, как ответить на запрос OPTIONS. Серверу просто нужно знать: доступен ли запрашиваемый URL-адрес только через аутентификацию на основе IP или за каким-либо брандмауэром или интрасетью? Если это так, то он должен отклонить запрос OPTIONS. Если это не так, то есть если ресурс доступен через общедоступный Интернет с помощью таких инструментов, как curl, wget, telnet или вашей любимой HTTP-библиотеки, тогда он должен разрешать запрос OPTIONS. Это даст браузерам такой же доступ, как и другим инструментам.

Затем сервер может принимать дальнейшие решения, когда поступает последующий запрос POST. Например, может быть, сервер хочет отклонить POST с неправильным Content-Type. Но он всегда хотел бы сделать это. Он не хотел бы отклонять запрос OPTIONS только от браузеров, поддерживающих CORS; вместо этого он должен отклонить запрос POST из любого источника.

(Причина, по которой браузеры являются особенными, заключается в следующем. Рассмотрим интрасеть, в которой используются плохие методы обеспечения безопасности и которую может прочитать любой, чей IP-адрес находится в определенном диапазоне, т. е. любой, кто использует компьютер компании. Обычно это не проблема: люди внутри компания, использующая curl, может получить доступ к данным, а люди за ее пределами, которые используют curl, не могут. Однако рассмотрим кого-то внутри компании, который просматривает какой-то вредоносный веб-сайт, https://evil.com/. Если evil.com использует XHR API для доступа к http://intranet/secret-data, то запрос будет поступать с привилегированного IP-адреса, поскольку запрос делает браузер на компьютере привилегированного пользователя. Протокол CORS был изобретен таким образом, что вместо прямого POST-запроса к http://intranet/secret-data, браузер сначала делает OPTI ONS-запрос, для которого весь http://intranet, скорее всего, ответит "нет, вы не можете получить доступ к этому", а затем POST никогда не происходит.)

person Domenic    schedule 08.01.2016
comment
Трудно получить, но кажется правильным. Я потрачу на это еще немного времени. Спасибо. - person smwikipedia; 17.01.2016