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

Question

По образцам из here:

Если запрос использует отличные от 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-х формах, которые не нуждаются в предполетный. Но может быть множество других возможностей. Суть в том, что сервер должен знать, почему отправляется запрос предполетной почты.

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

Answer 1

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

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

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

Access-Control-Allow-Origin: *

Даже если ресурс предоставляет дополнительную информацию на основе 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-адрес в определенном диапазоне, то есть любой, кто использует компьютер компании. Обычно это не проблема : люди внутри компании, которые используют завиток, могут получить доступ к данным, а люди за пределами нее, которые используют завиток, не могут. Однако подумайте о том, что кто-то внутри компании просматривает какой-то вредоносный веб-сайт, https://evil.com/. Если evil.com использует XHR API для доступа к http://intranet/secret-data, то запрос будет отправляться с привилегированного IP-адреса, так как это браузер на компьютере с привилегированным пользователем, выполняющий запрос. Чтобы предотвратить эти утечки безопасности, был разработан протокол CORS, чтобы вместо прямого POST до http://intranet/secret-data , t он сначала выполняет запрос OPTIONS, для которого все http://intranet, вероятно, просто скажут «нет, вы не можете получить доступ к этому», а затем POST никогда не произойдет.)