HTTP
Cross Origin i kontrola dostępu

Uwagi

Klient: wysyłanie żądania współdzielenia zasobów pochodzących z różnych źródeł (CORS)

Należy wysłać prośbę o pochodzenie, w tym nagłówek Origin . Wskazuje to, skąd pochodzi żądanie. Na przykład żądanie krzyżowego pochodzenia z http://example.com do http://example.org wyglądałoby tak:

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

Serwer użyje tej wartości do ustalenia, czy żądanie jest autoryzowane.

Serwer: odpowiadanie na żądanie CORS

Odpowiedź na żądanie CORS musi zawierać nagłówek Access-Control-Allow-Origin , który określa, które źródła mogą korzystać z zasobu CORS. Ten nagłówek może przyjąć jedną z trzech wartości:

• Pochodzenie W ten sposób zezwala się tylko na żądania z tego źródła .
• Postać * . Pozwala to na żądania z dowolnego źródła .
• Ciąg null . Pozwala to na brak żądań CORS .

Na przykład po otrzymaniu żądania CORS ze źródła http://example.com , jeśli example.com jest autoryzowanym źródłem, serwer odeśle tę odpowiedź:

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

Odpowiedź dowolnego pochodzenia pozwoliłaby również na to żądanie, tj .:

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

Zezwolenie na poświadczenia użytkownika lub sesję

Zezwolenie na wysyłanie poświadczeń użytkownika lub sesji użytkownika z żądaniem CORS pozwala serwerowi zachować dane użytkownika w żądaniach CORS. Jest to przydatne, jeśli serwer musi sprawdzić, czy użytkownik jest zalogowany przed podaniem danych (na przykład wykonanie czynności tylko wtedy, gdy użytkownik jest zalogowany - wymagałoby to wysłania żądania CORS z poświadczeniami).

Można to osiągnąć po stronie serwera dla żądań inspekcji wstępnej, wysyłając nagłówek Access-Control-Allow-Credentials w odpowiedzi na żądanie OPTIONS inspekcji wstępnej. Weź następujący przypadek żądania CORS, aby DELETE zasób:

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

Wiersz Access-Control-Allow-Credentials: true wskazuje, że następujące poświadczenie DELETE CORS może zostać wysłane z poświadczeniami użytkownika.

Żądania inspekcji wstępnej

W podstawowym żądaniu CORS można użyć tylko jednej z dwóch metod:

• OTRZYMAĆ
• POCZTA

i tylko kilka wybranych nagłówków. Żądania POST CORS mogą dodatkowo wybierać tylko z trzech typów treści.

Aby uniknąć tego problemu, żądania, które chcą użyć innych metod, nagłówków lub typów treści, muszą najpierw wydać żądanie inspekcji wstępnej , które jest żądaniem OPTIONS zawierającym nagłówki żądania kontroli dostępu. Na przykład jest to żądanie inspekcji wstępnej, które sprawdza, czy serwer zaakceptuje żądanie PUT zawierające nagłówek DNT :

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

Serwer: odpowiadanie na żądania inspekcji wstępnej

Gdy serwer otrzyma żądanie inspekcji wstępnej, musi sprawdzić, czy obsługuje żądaną metodę i nagłówki, i odesłać odpowiedź wskazującą jego zdolność do obsługi żądania, a także wszelkie inne dozwolone dane (takie jak poświadczenia).

Są one wskazane w nagłówkach Zezwalaj na kontrolę dostępu. Serwer może również odesłać nagłówek Max-Age kontroli dostępu, wskazujący, jak długo można buforować odpowiedź w trakcie inspekcji wstępnej.

Tak może wyglądać cykl żądanie-odpowiedź dla żądania wstępnego:

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