nginx 에서 크로스 필드 설정

앞 뒤 가 분 리 된 항목 에서 도 메 인 을 뛰 어 넘 는 문제 에 부 딪 힐 수 있 습 니 다.응용 로그 에 403 크로스 필드 오류 가 발생 했 을 때 No 'Access - Control - Allow - Origin' header is present on the required resource, Nginx 서버 에 응답 하 는 header 인 자 를 설정 해 야 합 니 다.
1. 범위 가 넓 을 때 nginx 의 사이트 설정 파일 에 다음 과 같이 추가 합 니 다.

   add_header 'Access-Control-Allow-Origin' '*';
   add_header 'Access-Control-Allow_Credentials' 'true';
   add_header 'Access-Control-Allow-Headers' 'Authorization,Accept,Origin,DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range';
   add_header 'Access-Control-Allow-Methods' 'GET,POST,OPTIONS,PUT,DELETE,PATCH';

2. 서술 어 에 제한 이 있다 면 다음 과 같이 추가 하면 됩 니 다.

    add_header Access-Control-Allow-Origin *;
    add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS';
    add_header Access-Control-Allow-Headers 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization';

    if ($request_method = 'OPTIONS') {
        return 204;
    }

3. 설정 항목 의 의미
(1) Access - Control - Allow - Origin: 서버 는 기본적으로 도 메 인 을 넘 을 수 없습니다.Nginx 서버 설정 Access-Control-Allow-Origin * 을 한 후 서버 가 모든 요청 원본 (Origin) 을 받 아들 일 수 있 음 을 표시 합 니 다. 즉, 모든 도 메 인 간 요청 을 받 아들 일 수 있 습 니 다.（2）Access-Control-Allow_Credentials: 서버 에서 클 라 이언 트 에 보 내 는 response 의 머리 필드 입 니 다. 클 라 이언 트 가 인증 정 보 를 가 져 갈 수 있 도록 하 는 것 입 니 다. 예 를 들 어 쿠키 와 같은 것 입 니 다.이렇게 하면 클 라 이언 트 가 크로스 도 메 인 요청 을 할 때 허 용 된 머리 를 휴대 할 수 있 고 인증 정 보 를 가 진 머리 도 휴대 할 수 있 습 니 다.(3) Access - Control - Allow - Headers: 다음 과 같은 오류 가 발생 하지 않도록 Request header field Content - Type is not allowed by Access - Control - Allow - Headers in preflight response. 이 오 류 는 현재 요청 한 Content - Type 의 값 이 지원 되 지 않 음 을 나 타 냅 니 다.사실은 프로그램 이 'application / json' 의 유형 요청 을 해서 생 긴 것 입 니 다.(4) Access - Control - Allow - Methods: 도 메 인 을 뛰 어 넘 는 서술 어 (GET, POST, OPTIONS, PUT, DELETE, PATCH, 앞의 세 개 를 자주 사용 합 니 다) 를 허용 합 니 다.다음 과 같은 오 류 를 방지 하기 위해 서 입 니 다. Content - Type is not allowed by Access - Control - Allow - Headers in preflight response. (5) OPTIONS 에 204 의 반환 을 추가 하 는 것 은 POST 요청 을 보 낼 때 Nginx 가 여전히 접근 을 거부 하 는 오 류 를 처리 하기 위해 서 입 니 다.'사전 검사 요청' 을 보 낼 때 는 방법 OPTIONS 가 필요 하기 때문에 서버 에서 이 방법 을 허용 해 야 합 니 다.OPTIONS 요청 은 특정한 목표 주소 에 대한 요청 이 어떤 제약 을 가 져 야 하 는 지 확인 하기 위해 '탐지' 요청 을 보 내 는 데 목적 을 둡 니 다.
4. 예비 검사 요청
CROS 는 전역 자원 공유 (Cross - origin resource sharing) 라 고 불 리 며 W3C 표준 입 니 다.그것 의 제 기 는 도 메 인 간 의 요 구 를 해결 하기 위 한 것 이다.
크로스 도 메 인 자원 공유 (CORS) 표준 에 HTTP 첫 번 째 필드 가 추가 되 었 습 니 다. 서버 가 어떤 소스 에 접근 할 수 있 는 권한 이 있 는 지 설명 할 수 있 습 니 다.또한 서버 데이터 에 부작용 을 일 으 킬 수 있 는 HTTP 요청 방법 (특히 GET 이외 의 HTTP 요청 또는 일부 MIME 형식의 POST 요청 과 결합) 을 규범화 해 야 합 니 다. 브 라 우 저 는 먼저 OPTIONS 방법 으로 사전 검사 요청 (preflight request) 을 해서 서버 에서 이 크로스 도 메 인 요청 을 허용 하 는 지 여 부 를 알 아야 합 니 다.서버 가 허용 을 확인 한 후에 야 실제 HTTP 요청 을 시작 합 니 다.사전 검사 요청 의 반환 에서 서버 측 에서 도 클 라 이언 트 에 게 신분증 (Cookies 와 HTTP 인증 관련 데이터 포함) 을 휴대 해 야 하 는 지 알 릴 수 있다.
Content - type 필드 의 유형 은 application / json 입 니 다. 요청 은 위 에서 말 한 MIME 형식의 POST 요청 입 니 다. CORS 에 따 르 면 Content - type 은 아래 MIME 유형 에 속 하지 않 고 모두 예비 검사 요청 에 속 합 니 다.

application/x-www-form-urlencoded
multipart/form-data
text/plain

따라서 application / json 의 요청 은 정식 통신 에 앞서 '예비 검사' 요청 을 한 번 추가 합 니 다. 이번 '예비 검사' 요청 은 머리 정 보 를 가 져 옵 니 다 Access - Control - Request - Headers: Content - Type:
OPTIONS /api/test HTTP/1.1 Origin: http://foo.example Access - Control - Request - Method: POST Access - Control - Request - Headers: Content - Type... 서버 가 응답 할 때 돌아 오 는 머리 정보 에 Access - Control - Allow - Headers: Content - Type 이 포함 되 어 있 지 않 으 면 기본 값 이 아 닌 Content - Type 을 받 아들 이지 않 는 다 는 뜻 입 니 다.즉, 다음 오류 가 발생 했 습 니 다. 요청 헤더 필드 Content - Type 은 사전 비행 응답 시 Access - Control - Allow - Headers 에서 허용 하지 않 습 니 다.
두 가지 부탁
브 라 우 저 는 CORS 요청 을 두 가지 로 나 누 었 습 니 다. 간단 한 요청 (simple request) 과 간단 하지 않 은 요청 (not - so - simple request) 입 니 다.(1) 다음 과 같은 두 가지 조건 을 동시에 만족 시 키 면 간단 한 요구 에 속한다.a. 요청 방법 은 다음 과 같은 세 가지 방법 중 하나 입 니 다. HEAD GET POST b. HTTP 의 헤더 정 보 는 다음 과 같은 몇 가지 필드 를 초과 하지 않 습 니 다. Accept Accept - language Content - language Last - 이벤트 - ID Content - type: 세 가지 값 으로 만 application / x - www - form - urlencoded, multipart / form - data, text / plain
(2) 위의 두 가지 조건 을 동시에 만족 시 키 지 않 으 면 간단 하지 않 은 요구 에 속한다.
6 요청 절차
(1) 간단 한 요청 에 대해 브 라 우 저 는 CORS 요청 을 직접 보 냅 니 다.구체 적 으로 헤더 정보 에 Origin 필드 를 추가 하 는 것 이다.
(2) 간단 하지 않 고 간단 하지 않 은 요청 은 서버 에 특별한 요구 가 있 는 요청 입 니 다. 예 를 들 어 요청 방법 은 PUT 나 DELETE 또는 Content - type 필드 의 유형 은 application / json 입 니 다.단순 요청 이 아 닌 CORS 요청 은 정식 통신 에 앞서 HTTP 조회 요청 을 한 번 추가 해 '사전 점검' 요청 (preflight) 이 라 고 한다.
브 라 우 저 는 서버 에 현재 웹 페이지 가 있 는 도 메 인 이름 이 서버 의 허가 명단 에 있 는 지, 그리고 어떤 HTTP 동사 와 헤더 정보 필드 를 사용 할 수 있 는 지 물 어 봅 니 다.긍정 적 인 답변 을 받 아야 브 라 우 저 에서 정식 XML HttpRequest 요청 을 할 수 있 습 니 다. 그렇지 않 으 면 오류 가 발생 합 니 다.
참고 주소:http://www.ruanyifeng.com/blog/2016/04/cors.html