CORB (Cross-Origin Read Blocking)

Jquery AJAX를 사용하여 타사 API를 호출했습니다. 콘솔에서 다음과 같은 오류가 발생합니다.

CORB (Cross-Origin Read Blocking) 가 MIME 유형 application / json을 사용하여 교차 출처 응답 내 URL 을 차단했습니다 . 참조 https://www.chromestatus.com/feature/5629709824032768을 자세한 내용은.

Ajax 호출에 다음 코드를 사용했습니다.

$.ajax({
  type: 'GET',
  url: My Url,
  contentType: 'application/json',
  dataType:'jsonp',
  responseType:'application/json',
  xhrFields: {
    withCredentials: false
  },
  headers: {
    'Access-Control-Allow-Credentials' : true,
    'Access-Control-Allow-Origin':'*',
    'Access-Control-Allow-Methods':'GET',
    'Access-Control-Allow-Headers':'application/json',
  },
  success: function(data) {
    console.log(data);
  },
  error: function(error) {
    console.log("FAIL....=================");
  }
});

Fiddler를 체크인했을 때 Ajax 성공 방법이 아닌 응답으로 데이터를 얻었습니다.

제발 도와주세요.

 dataType:'jsonp',

JSONP 요청을하고 있지만 서버가 JSON으로 응답하고 있습니다.

브라우저는 보안 위험이 있으므로 JSON을 JSONP로 취급하는 것을 거부합니다. (브라우저 가 JSON을 JSONP로 처리하려고하면 기껏해야 실패합니다).

참조 이 질문 JSONP가 무엇인지에 대한 자세한 내용을. CORS가 사용 가능하기 전에 사용 된 동일한 출처 정책을 해결하기위한 불쾌한 해킹입니다. CORS는 문제에 대한 훨씬 깨끗하고 안전하며 강력한 솔루션입니다.

출처 간 요청을 시도하고 있으며 충돌하는 명령의 거대한 더미에 생각할 수있는 모든 것을 던지고있는 것 같습니다.

동일한 출처 정책이 어떻게 작동하는지 이해해야합니다.

자세한 가이드는 이 질문 을 참조하세요 .

이제 코드에 대한 몇 가지 참고 사항 :

contentType: 'application/json',

• JSONP를 사용할 때 무시됩니다.
• GET 요청을하고 있습니다. 유형을 설명하는 요청 본문이 없습니다.
• 이렇게하면 원본 간 요청이 단순하지 않게됩니다. 즉, 기본 CORS 권한뿐 아니라 사전 비행도 처리해야합니다.

그것을 제거하십시오.

 dataType:'jsonp',

• 서버가 JSONP로 응답하지 않습니다.

이것을 제거하십시오. (서버가 대신 JSONP로 응답하도록 만들 수 있지만 CORS가 더 좋습니다).

responseType:'application/json',

이것은 jQuery.ajax에서 지원하는 옵션이 아닙니다. 이것을 제거하십시오.

xhrFields : {withCredentials : false},

이것이 기본값입니다. ajaxSetup으로 true로 설정하지 않는 한 이것을 제거하십시오.

  headers: {
    'Access-Control-Allow-Credentials' : true,
    'Access-Control-Allow-Origin':'*',
    'Access-Control-Allow-Methods':'GET',
    'Access-Control-Allow-Headers':'application/json',
  },

• 이들은 응답 헤더입니다. 그들은 요청이 아니라 응답에 속합니다.
• 이렇게하면 원본 간 요청이 단순하지 않게됩니다. 즉, 기본 CORS 권한뿐 아니라 사전 비행도 처리해야합니다.

대부분의 경우 차단 된 응답은 웹 페이지의 동작에 영향을주지 않아야하며 CORB 오류 메시지는 무시해도됩니다. 예를 들어 차단 된 응답의 본문이 이미 비어 있거나 응답이 처리 할 수없는 컨텍스트 (예 : 404 오류 페이지와 같은 HTML 문서)로 전달 될 때 경고가 발생할 수 있습니다. 태그로 전달됨).

https://www.chromium.org/Home/chromium-security/corb-for-developers

내 브라우저의 캐시를 정리해야했는데이 링크를 읽고 있는데 요청이 빈 응답을 받으면이 경고 오류가 발생합니다. 요청에 대한 CORS를 받고 있었기 때문에이 요청의 응답이 비었으므로 브라우저의 캐시를 지우고 CORS가 사라졌습니다. 크롬이 캐시에 PORT 번호를 저장했기 때문에 CORS를 받고 있었기 때문에 서버는 캐시로 인해 수락 localhost:3010하고 localhost:3002.

헤더가 'Access-Control-Allow-Origin : *'인 응답을 반환합니다. 아래 코드에서 Php 서버 응답을 확인하십시오.

<?php header('Access-Control-Allow-Origin: *');
header('Content-Type: application/json');
echo json_encode($phparray); 

서버 측에 CORS를 추가해야합니다.

nodeJS 를 사용 하는 경우 :

먼저 아래 명령을 사용하여 설치해야합니다 cors .

npm install cors --save

이제 ( ) 와 같은 앱 시작 파일에 다음 코드 를 추가하십시오.app.js or server.js

var express = require('express');
var app = express();

var cors = require('cors');
var bodyParser = require('body-parser');

//enables cors
app.use(cors({
  'allowedHeaders': ['sessionId', 'Content-Type'],
  'exposedHeaders': ['sessionId'],
  'origin': '*',
  'methods': 'GET,HEAD,PUT,PATCH,POST,DELETE',
  'preflightContinue': false
}));

require('./router/index')(app);

질문에서 명확하지 않지만 이것이 개발 또는 테스트 클라이언트에서 발생하는 일이라고 가정하고 이미 Fiddler를 사용하고 있다면 Fiddler가 허용 응답으로 응답하도록 할 수 있습니다.

• Fiddler에서 문제 요청 선택
• AutoResponder탭 열기
• Add Rule규칙을 클릭 하고 편집하여 다음을 수행하십시오.
  • 방법 : OPTIONS 서버 URL 여기 , 예Method:OPTIONS http://localhost
  • *CORSPreflightAllow
• 검사 Unmatched requests passthrough
• 검사 Enable Rules

몇 가지 참고 사항 :

1. 분명히 이것은 API 서비스를 수정하는 것이 불가능하거나 실용적이지 않은 개발 / 테스트를위한 솔루션 일뿐입니다.
2. 타사 API 제공 업체와 맺은 계약이이를 수행하도록 허용하는지 확인합니다.
3. 다른 사람들이 언급했듯이 이것은 CORS 작동 방식의 일부이며 결국 헤더는 API 서버에 설정되어야합니다. 해당 서버를 제어하는 ​​경우 헤더를 직접 설정할 수 있습니다. 이 경우 타사 서비스이므로 원래 사이트의 URL을 제공 할 수있는 일부 메커니즘이 있다고 가정 할 수 있으며 올바른 헤더로 응답하도록 서비스를 업데이트 할 것입니다.

localhost에서 작업하는 경우 이것을 시도하십시오. 이것은 나를 위해 일한 유일한 확장 및 방법입니다 (Angular, 자바 스크립트 만, PHP 없음)

https://chrome.google.com/webstore/detail/moesif-orign-cors-changer/digfbfaphojjndkpccljibejjbppifbc/related?hl=ko

dataTypeajax 요청을에서 jsonp로 변경해 보셨습니까 json? 그것은 내 경우에 그것을 고쳤습니다.

Chrome 확장 프로그램에서 다음을 사용할 수 있습니다.

chrome.webRequest.onHeadersReceived.addListener

서버 응답 헤더를 다시 작성합니다. 기존 헤더를 바꾸거나 추가 헤더를 추가 할 수 있습니다. 다음은 원하는 헤더입니다.

Access-Control-Allow-Origin: *

https://developers.chrome.com/extensions/webRequest#event-onHeadersReceived

나는 CORB 문제에 갇혀 있었고 이것은 나를 위해 해결되었습니다.

응답 헤더는 일반적으로 서버에 설정됩니다. 설정 'Access-Control-Allow-Headers'에 'Content-Type'서버 측

Cross-Origin Read Blocking (CORB)은 의심스러운 cross-origin 리소스로드가 웹 페이지에 도달하기 전에 웹 브라우저에 의해 식별되고 차단 될 수있는 알고리즘입니다. 브라우저가 특정 cross-origin 네트워크 응답을 제공하지 못하도록 설계되었습니다. 웹 페이지에.

먼저 이러한 리소스가 올바른 " Content-Type"(예 : JSON MIME 유형- " text/json", " application/json", HTML MIME 유형- " text/html") 로 제공되는지 확인하십시오 .

둘째 : 모드를 cors로 설정합니다. mode:cors

가져 오기는 다음과 같습니다.

 fetch("https://example.com/api/request", {
            method: 'POST',
            body: JSON.stringify(data),
            mode: 'cors',
            headers: {
                'Content-Type': 'application/json',
                "Accept": 'application/json',
            }
        })
    .then((data) => data.json())
    .then((resp) => console.log(resp))
    .catch((err) => console.log(err))

참조 : https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md

https://www.chromium.org/Home/chromium-security/corb-for-developers

이 맥락에서 언급 할 가치가있는 경우가 있습니다. Chrome (적어도 일부 버전) 은 CORB에 설정된 알고리즘을 사용하여 CORS 프리 플라이트를 확인합니다 . IMO, 이것은 프리 플라이트가 CORB 위협 모델에 영향을 미치지 않는 것 같고 CORB가 CORS와 직교하도록 설계 되었기 때문에 약간 어리석은 일입니다. 또한 CORS 프리 플라이트의 본문에 액세스 할 수 없으므로 성가신 경고 만 발생하는 부정적인 결과는 없습니다.

어쨌든 CORS 프리 플라이트 응답 (OPTIONS 메서드 응답)에 body (204)가 없는지 확인하세요 . 콘텐츠 유형이 application / octet-stream이고 길이가 0 인 빈 200도 여기서도 잘 작동했습니다.

메시지 본문이있는 CORB 경고 대 OPTIONS 응답을 계산하여이 경우에 해당하는지 확인할 수 있습니다.

이 경고는 200으로 빈 응답을 보낼 때 발생한 것으로 보입니다.

이 구성은 .htaccessChrome에 경고를 표시합니다.

Header always set Access-Control-Allow-Origin "*"
Header always set Access-Control-Allow-Methods "POST,GET,HEAD,OPTIONS,PUT,DELETE"
Header always set Access-Control-Allow-Headers "Access-Control-Allow-Headers, Origin,Accept, X-Requested-With, Content-Type, Access-Control-Request-Method, Access-Control-Request-Headers, Authorization"

RewriteEngine On
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule .* / [R=200,L]

그러나 마지막 줄을

RewriteRule .* / [R=204,L]

문제를 해결하십시오!

내 Chrome 확장 프로그램에서 동일한 문제가 발생했습니다. 내 매니페스트 "content_scripts"옵션에이 부분을 추가하려고 할 때 :

//{
    //  "matches": [ "<all_urls>" ],
    //  "css": [ "myStyles.css" ],
    //  "js": [ "test.js" ]
    //}

그리고 내 매니페스트 "권한"에서 다른 부분을 제거합니다.

"https://*/"

내 XHR 요청 중 하나에서 CORB를 삭제할 때만 사라집니다.

가장 나쁜 것은 내 코드에 XHR 요청이 거의없고 그중 하나만 CORB 오류가 발생하기 시작한다는 것입니다 (왜 CORB가 다른 XHR에 표시되지 않는지, 매니페스트 변경이이 오류를 공동으로 사용한 이유). 그래서 전체 코드를 몇 시간 씩 반복해서 검사하고 많은 시간을 잃었습니다.

사파리에서 수행하는 경우 시간이 걸리지 않습니다. 환경 설정 >> 개인 정보에서 개발자 메뉴를 활성화하고 개발 메뉴에서 "교차 출처 제한 비활성화"를 선택 해제하십시오. 로컬 전용을 원하는 경우 개발자 메뉴를 활성화하고 개발 메뉴에서 "로컬 파일 제한 비활성화"를 선택하기 만하면됩니다.

OSX 용 Chrome에서 터미널을 열고 다음을 실행합니다.

$ open -a Google\ Chrome --args --disable-web-security --user-data-dir

--user-data-dir은 OSX의 Chrome 49 이상에서 필요합니다.

Linux의 경우 다음을 실행하십시오.

$ google-chrome --disable-web-security

또한 AJAX 또는 JSON과 같은 개발 목적으로 로컬 파일에 액세스하려는 경우이 플래그도 사용할 수 있습니다.

-–allow-file-access-from-files

Windows의 경우 명령 프롬프트로 이동하여 Chrome.exe가있는 폴더로 이동하여 다음을 입력합니다.

chrome.exe --disable-web-security

그러면 동일한 원본 정책이 비활성화되고 로컬 파일에 액세스 할 수 있습니다.

서버의 jsonp 응답 형식이 잘못 되었기 때문에이 문제가 발생했습니다. 오답은 다음과 같습니다.

callback(["apple", "peach"])

문제는 내부의 객체 callback가 json 배열 대신 올바른 json 객체 여야한다는 것입니다. 그래서 일부 서버 코드를 수정하고 형식을 변경했습니다.

callback({"fruit": ["apple", "peach"]})

브라우저는 수정 후 기꺼이 응답을 수락했습니다.

Google 크롬에서 문제가 발생하면 "Moesif CORS"확장을 설치해보십시오. Cross origin request이므로 응답 상태 코드가 200 인 경우에도 크롬은 응답을받지 않습니다.