HTTP
Перекрестное происхождение и контроль доступа

замечания

Клиент: отправка запроса на совместное использование ресурсов (CORS)

Запрос перекрестного происхождения должен быть отправлен, включая заголовок Origin . Это указывает, откуда возник запрос. Например, запрос перекрестного происхождения с http://example.com на http://example.org будет выглядеть следующим образом:

GET /cors HTTP/1.1
Host: example.org
Origin: example.com

Сервер будет использовать это значение, чтобы определить, разрешен ли запрос.

Сервер: ответ на запрос CORS

Ответ на запрос CORS должен включать заголовок Access-Control-Allow-Origin , который диктует, каким истокам разрешено использовать ресурс CORS. Этот заголовок может принимать одно из трех значений:

• Происхождение. Выполнение этого разрешает только запросы из этого источника .
• Символ * . Это разрешает запросы из любого источника .
• Строка null . Это не позволяет запросам CORS .

Например, при получении запроса CORS из источника http://example.com , если example.com является авторизованным источником, сервер отправит ответ:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: example.com

Ответ на любой источник также разрешает этот запрос, то есть:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *

Разрешение учетных данных пользователя или сеанса

Разрешение учетных данных пользователя или сеанса пользователя, отправляемых с запросом CORS, позволяет серверу сохранять данные пользователя через запросы CORS. Это полезно, если серверу необходимо проверить, вошел ли пользователь в систему перед предоставлением данных (например, только выполнение действия, если пользователь вошел в систему), для этого требуется, чтобы запрос CORS был отправлен с учетными данными).

Это может быть достигнуто на стороне сервера для предполетных запросов, отправив заголовок Access-Control-Allow-Credentials в ответ на запрос предварительной OPTIONS . Возьмем следующий случай запроса CORS для DELETE ресурса:

OPTIONS /cors HTTP/1.1
Host: example.com
Origin: example.org
Access-Control-Request-Method: DELETE

HTTP/1.1 200 OK
Access-Control-Allow-Origin: example.org
Access-Control-Allow-Methods: DELETE
Access-Control-Allow-Credentials: true

Строка Access-Control-Allow-Credentials: true указывает, что следующий запрос DELETE CORS может быть отправлен с учетными данными пользователя.

Запросы предварительной проверки

В базовом запросе CORS можно использовать один из двух методов:

• ПОЛУЧИТЬ
• СООБЩЕНИЕ

и только несколько заголовков. Запросы POST CORS могут дополнительно выбирать только из трех типов контента.

Чтобы избежать этой проблемы, запросы, которые хотят использовать другие методы, заголовки или типы контента, должны сначала выдать запрос предварительной проверки , который является запросом OPTIONS который включает заголовки запроса контроля доступа. Например, это запрос предполетной проверки, который проверяет, примет ли сервер запрос PUT который включает в себя заголовок DNT :

OPTIONS /cors HTTP/1.1
Host: example.com
Origin: example.org
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: DNT

Сервер: ответ на предполетные запросы

Когда сервер получает запрос перед полетом, он должен проверить, поддерживает ли он запрашиваемый метод и заголовки, и отсылает ответ, который указывает его способность поддерживать запрос, а также любые другие разрешенные данные (такие как учетные данные).

Они указаны в контроле доступа. Сервер также может отправить обратно заголовок Max-Age контроля доступа, указывающий, на сколько времени может быть кэширован запрос перед полетом.

Вот как выглядит запрос-ответ для запроса предполетной проверки:

OPTIONS /cors HHTP/1.1
Host: example.com
Origin: example.org
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: DNT

HTTP/1.1 200 OK
Access-Control-Allow-Origin: example.org
Access-Control-Allow-Methods: PUT
Access-Control-Allow-Headers: DNT