Возможно ли уловить ошибки CORS?

Question

Этот вопрос связан с совместным использованием ресурсов Cross-Origin (CORS, http://www.w3.org/TR/cors/).

При возникновении ошибки при выполнении запроса CORS Chrome (и другие браузеры AFAIK также) регистрирует ошибку на консоли ошибок. Пример сообщения может выглядеть так:

XMLHttpRequest не может загрузить http://domain2.example. Происхождение http://domain1.example не разрешено Access-Control-Allow-Origin.

Мне интересно, есть ли способ программно получить это сообщение об ошибке? Я попытался обернуть мой вызов xhr.send() в try/catch, я также попытался добавить обработчик событий onerror(). Ни один из которых не получает сообщение об ошибке.

Answer 1

См:

• http://www.w3.org/TR/cors/#handling-a-response-to-a-cross-origin-request

... а также отмечает в XHR 2-го уровня около CORS:

• http://www.w3.org/TR/XMLHttpRequest2/

информация намеренно фильтруют.

Редактировать много месяцев спустя: Следующий комментарий здесь спросил «почему»; на якоре в первом звене не хватало нескольких символов, из-за чего было трудно увидеть, в какой части документа я имел в виду.

Это вещь безопасности - попытка избежать раскрытия информации в заголовках HTTP, которые могут быть чувствительными. W3C ссылка о CORS говорит:

Агенты пользователей должны отфильтровать все, кроме тех, которые являются простым заголовком ответа или из которых заголовков ответа имя поля является ASCII регистронезависимого матчем для одного из значений Access-Control-Expose-Headers (если есть), прежде чем подвергать заголовки ответов API-интерфейсам, определенным в спецификациях API CORS.

Этот проход содержит ссылки для «простого заголовка ответа», в котором перечислены Cache-Control, Content-Language, Content-Type, Expires, Last-Modified и Pragma. Так что те передаются. Заголовок заголовка «Access-Control-Expose-Headers» позволяет удаленному серверу выставлять другие заголовки, перечисляя их там. Дополнительную информацию см. В документации W3C.

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

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

Это может затруднить отладку, но это соображение безопасности и удобства использования, когда, поскольку «пользователь» является разработчиком в этом контексте, безопасность имеет существенный приоритет.