교차 출처 리소스 공유 활성화
게시 됨: 2016-11-07CORS(교차 출처 리소스 공유)란 무엇입니까?
교차 출처 리소스 공유는 숨겨진 리소스를 표시할 수 있는 기본입니다. CORS(Cross-Origin Resource Sharing)는 도메인 경계를 넘어 진정한 개방형 액세스를 가능하게 하는 사양입니다. CORS를 사용하면 웹 스크립트가 원래 도메인 외부의 콘텐츠와 더 공개적으로 상호 작용할 수 있으므로 웹 서비스 간의 통합이 향상됩니다. 교차 출처 리소스 공유를 사용하면 웹 페이지에서 글꼴과 같은 차단된 리소스를 리소스가 시작된 도메인 외부의 다른 도메인에서 요청할 수 있습니다.
CORS는 교차 출처 요청을 허용하는 것이 안전한지 여부를 결정하기 위해 브라우저와 서버가 상호 작용할 수 있는 방법을 정의합니다. 순수한 동일 출처 요청보다 더 많은 자유와 기능을 허용하지만 단순히 모든 교차 출처 요청을 허용하는 것보다 더 안전합니다.
CORS가 왜 중요한가요?
JavaScript와 웹 프로그래밍은 수년에 걸쳐 비약적으로 성장했지만 동일 출처 정책은 여전히 남아 있습니다. 이것은 JavaScript가 도메인 경계를 넘어 요청하는 것을 방지하고 도메인 간 요청을 만들기 위한 다양한 해킹을 발생시켰습니다.
CORS는 도메인 간 요청을 구현하기 위해 모든 브라우저에서 사용할 수 있는 표준 메커니즘을 도입합니다. 사양은 브라우저와 서버가 어떤 요청이 허용되는지(그리고 허용되지 않는지) 통신할 수 있도록 하는 헤더 집합을 정의합니다. CORS는 모두에게 API 액세스를 제공함으로써 개방형 웹의 정신을 이어갑니다.
교차 출처 리소스 공유 활성화 –
1. 아파치의 CORS
Apache를 사용하여 헤더에 CORS 인증을 추가하려면 서버 구성의 <Directory> , <Location> <Files> 또는 <VirtualHost> 섹션 안에 다음 줄을 추가하기만 하면 됩니다(일반적으로 다음과 같은 *.conf 파일에 있습니다. httpd.conf 또는 apache.conf) 또는 .htaccess 파일 내:
헤더 세트 Access-Control-Allow-Origin "*"
변경 사항이 올바른지 확인하려면 다음을 사용하는 것이 좋습니다.
아파치 -t
구성 변경에 오류가 있는지 확인합니다. 이 단계가 지나면 명령을 실행하여 변경 사항이 적용되었는지 확인하기 위해 Apache를 다시 로드해야 할 수 있습니다.
sudo 서비스 apache2 다시 로드
또는
apachectl -k 우아한
헤더를 변경하려면 mod_headers를 사용해야 합니다. Mod_headers는 Apache에서 기본적으로 활성화되어 있지만 실행에 의해 활성화되었는지 확인하고 싶을 수 있습니다.
a2enmod 헤더
참고 : set 대신 add 를 사용할 수도 있지만 add 는 헤더를 여러 번 추가할 수 있으므로 set을 사용하는 것이 더 안전합니다.
2. App Engine의 CORS
Google App Engine의 Python 기반 애플리케이션의 경우 다음과 같이 self.response.headers.add_header() 메서드를 사용할 수 있습니다.
클래스 CORSEnabledHandler(webapp.RequestHandler):
def get(자신):
self.response.headers.add_header("접근 제어 허용 원본", "*")
self.response.headers['콘텐츠 유형'] = '텍스트/csv'
self.response.out.write(self.dump_csv()) Java 기반 애플리케이션의 경우 resp.addHeader() 를 사용합니다.
공개 무효 doGet(HttpServletRequest 요청, HttpServletResponse 응답) {
resp.addHeader("접근 제어 허용 원본", "*");
resp.addHeader("콘텐츠 유형", "텍스트/csv");
resp.getWriter().append(csvString);
} 그리고 Go 기반 애플리케이션의 경우 w.Header().Add() 를 사용합니다.
func doGet(w http.ResponseWriter, r *http.Request) {
w.Header().Add("액세스 제어 허용 원본", "*")
w.Header().Add("콘텐츠 유형", "텍스트/csv")
fmt.Fprintf(w, csvData)
}
3. ASP.NET의 CORS
IIS를 구성할 수 있는 액세스 권한이 없는 경우에도 원본 페이지에 다음 줄을 추가하여 ASP.NET을 통해 헤더를 추가할 수 있습니다.
Response.AppendHeader("접근 제어 허용 원본", "*");
ASP.NET 웹 API
ASP.NET Web API 2는 CORS를 지원합니다.
CORS 지원을 활성화하려면 프로젝트에 Microsoft.AspNet.WebApi.Cors NuGet 패키지를 추가합니다.
구성에 다음 코드를 추가합니다.
공개 정적 무효 레지스터(HttpConfiguration 구성)
{
// 새 코드
config.EnableCors();
}교차 출처 요청을 활성화하려면 Web API 컨트롤러 또는 컨트롤러 메서드에 [EnableCors] 특성을 추가합니다.
[EnableCors(origins: "http://example.com", 헤더: "*", 메소드: "*")]
공개 클래스 TestController : ApiController
{
// 컨트롤러 메소드가 표시되지 않음...
}
전역적으로 활성화
위에서 설명한 방법을 사용하여 각 컨트롤러에 주석을 추가하지 않고 API에서 CORS를 활성화할 수도 있습니다.
공개 정적 무효 레지스터(HttpConfiguration 구성)
{
var corsAttr = 새로운 EnableCorsAttribute("http://example.com", "*", "*");
config.EnableCors(corsAttr);
}
4. AWS API 게이트웨이의 CORS
Amazon API Gateway는 API Gateway 콘솔의 간단한 버튼을 통해 CORS 활성화에 대한 지원을 추가합니다. 불행히도 그 버튼에는 부분적인 동작이 있으므로 200개의 답변에 대해서만 CORS를 올바르게 설정하고(다른 HTTP 상태 코드는 제외) Jquery 헤더 지원을 무시합니다. 지금까지 고려된 최상의 솔루션은 CORS 버튼을 사용하지 않고 수동으로 구성을 설정하는 것입니다.
이것은 몇 가지 단계로 달성할 수 있습니다.
1. API Gateway 콘솔에 로그인
2. CORS를 설정하기 전에 해당 메소드와 함께 노출되어야 하는 모든 REST 리소스를 생성합니다(CORS를 활성화한 후 새 리소스/메소드를 생성하는 경우 이러한 단계를 반복해야 함).
3. 리소스 선택
4. OPTIONS 메소드 추가, 통합 유형 "mock"으로 선택
5. 자원의 각 메소드에 대해
6. 응답 방법으로 이동
7. 지원해야 하는 모든 응답 방법 추가(예: 200, 500 등)
8. 각 응답 코드에 대해 응답 헤더를 다음으로 설정합니다.
X-요청된-함께
액세스 제어 허용 헤더
접근-제어-허용-원점
액세스 제어 허용 방법
9. 통합 응답으로 이동하여 생성된 응답 코드 중 하나를 선택한 다음 헤더 매핑을 선택합니다.
10. 헤더의 기본값 삽입
예시:
X-Requested-With: '*'
Access-Control-Allow-Headers: '콘텐츠 유형, X-Amz-Date, 인증, X-API-Key, x-requested-with'
액세스 제어 허용 출처: '*'
액세스 제어 허용 방법: 'POST, GET, OPTIONS'
이 작업은 새로 생성된 OPTIONS를 포함하여 각 방법에 대해 반복되어야 합니다.
11. API를 단계에 배포
12. http://client.cors-api.appspot.com/client를 사용하여 CORS 요청이 성공적으로 활성화되었는지 확인합니다.
5. Caddyserver의 CORS
Caddy를 사용하여 헤더에 CORS 인증을 추가하려면 caddyfile 내부에 다음 행을 추가하기만 하면 됩니다.
코르
이렇게 하면 모든 도메인에서 모든 리소스에 액세스할 수 있습니다.
또한 더 구체적일 수 있습니다. 즉, 특정 도메인에 특정 리소스를 허용합니다.
cors /foo http://mysite.com http://anothertrustedsite.com
사용할 수 있는 더 많은 옵션이 있습니다. 다음은 caddyserver 문서에 표시된 전체 예입니다.
코르 / {
출처 http://allowedSite.com
출처 http://anotherSite.org https://anotherSite.org
메소드 POST,PUT
allow_credentials 거짓
최대 연령 3600
allowed_headers X-Custom-Header, X-Foobar
exposed_headers X-Something-Special,SomethingElse
}
6. CGI 스크립트의 CORS
다음 줄을 출력하십시오.
액세스 제어 허용 출처: *
.. 예를 들어 Perl에서(CGI.pm 사용) CGI 스크립트 헤더의 일부로:
인쇄 헤더( -유형 => '텍스트/거북이', -content_location => 'mydata.ttl', -access_control_allow_origin => '*', );
7. Perl PSGI 스크립트의 CORS
Plack::Middleware::CrossOrigin 모듈은 완전한 CORS 서버 측 구현을 제공합니다. 모든 위치에서 요청을 허용하려면 다음을 빌더에 추가하기만 하면 됩니다.
'CrossOrigin' 활성화, origins => '*';
8. 파이썬의 CORS
"콘텐츠 유형: 텍스트/거북이" 인쇄 "콘텐츠 위치: mydata.ttl" 인쇄 "접근-제어-허용-원본: *" 인쇄
9. ExpressJS의 CORS
node.js의 ExpressJS 앱에서 경로에 대해 다음을 수행합니다.
app.use(함수(요청, 해상도, 다음) {
res.header("접근-제어-허용-원본", "*");
res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept");
다음();
});
app.get('/', function(req, res, next) {
// 이 경로에 대한 get 처리
});
app.post('/', function(req, res, next) {
// 이 경로에 대한 게시물을 처리합니다.
});
10. IIS6의 CORS
CORS를 활성화하려면 Microsoft IIS6을 다음 단계를 수행하십시오.
- 인터넷 정보 서비스(IIS) 관리자 열기
- CORS를 활성화하려는 사이트를 마우스 오른쪽 버튼으로 클릭하고 속성 으로 이동합니다.
- HTTP 헤더 탭으로 변경
- 사용자 지정 HTTP 헤더 섹션에서 추가 를 클릭합니다.
- 헤더 이름으로
Access-Control-Allow-Origin을 입력하십시오. - 헤더 값으로
*를 입력합니다. - 확인 을 두 번 클릭
11. IIS7의 CORS
Microsoft IIS7의 경우 다음을 애플리케이션 또는 사이트 루트의 web.config 파일에 병합합니다.
<?xml 버전="1.0" 인코딩="utf-8"?>
<구성>
<시스템.웹서버>
<http프로토콜>
<커스텀 헤더>
<이름 추가="액세스 제어 허용-원본" 값="*" />
</customHeaders>
</http프로토콜>
</시스템.웹서버>
</구성> web.config 파일이 아직 없거나 파일이 무엇인지 모르는 경우 위의 스니펫이 포함된 web.config 라는 새 파일을 만드십시오.
12. 유성의 CORS
Meteor 애플리케이션에 CORS 인증을 추가하려면 webapp 패키지의 WebApp.connectHandlers 를 사용하여 HTTP 헤더를 사용자 정의하십시오.
// 들어오는 HTTP 요청을 수신합니다. 서버에서만 사용할 수 있습니다.
WebApp.rawConnectHandlers.use(function(req, res, next) {
res.setHeader("접근-제어-허용-원본", "*");
다음 반환();
}); 지정된 문자열과 일치하는 경로의 핸들러만 호출하려면 선택적 path 인수를 사용하십시오.
// 들어오는 HTTP 요청을 수신합니다. 서버에서만 사용할 수 있습니다.
WebApp.rawConnectHandlers.use("/public", function(req, res, next) {
res.setHeader("접근-제어-허용-원본", "*");
다음 반환();
});
13. Nginx의 CORS
다음 Nginx 구성은 실행 전 요청을 지원하는 CORS를 활성화합니다.

#
# nginx를 위한 폭넓은 CORS 구성
#
위치 / {
if ($request_method = '옵션') {
add_header '접근-제어-허용-원본' '*';
add_header '액세스 제어 허용 방법' 'GET, POST, OPTIONS';
#
# 다양한 브라우저에서 사용자 정의 헤더와 헤더를 *해야 하지만* 그렇지 않습니다.
#
add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type';
#
# 이 비행 전 정보는 20일 동안 유효하다고 고객에게 알립니다.
#
add_header '접근 제어 최대 연령' 1728000;
add_header '콘텐츠 유형' '텍스트/일반 문자 집합=UTF-8';
add_header '콘텐츠 길이' 0;
리턴 204;
}
if ($request_method = 'POST') {
add_header '접근-제어-허용-원본' '*';
add_header '액세스 제어 허용 방법' 'GET, POST, OPTIONS';
add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type';
}
if ($request_method = 'GET') {
add_header '접근-제어-허용-원본' '*';
add_header '액세스 제어 허용 방법' 'GET, POST, OPTIONS';
add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type';
}
}
14. Perl PSGI 스크립트의 CORS
Plack::Middleware::CrossOrigin 모듈은 완전한 CORS 서버 측 구현을 제공합니다. 모든 위치에서 요청을 허용하려면 다음을 빌더에 추가하기만 하면 됩니다.
'CrossOrigin' 활성화, origins => '*';
이 모듈은 Debian 및 Ubuntu에서도 libprack-middleware-crossorigin-perl로 사용할 수 있습니다.
15. PHP의 CORS
Apache를 구성할 수 있는 액세스 권한이 없는 경우에도 PHP 스크립트에서 헤더를 보낼 수 있습니다. PHP 스크립트에 다음을 추가한 경우입니다.
<?php
header("접근-제어-허용-원본: *");참고: PHP 헤더 기능의 모든 사용과 마찬가지로 이것은 출력이 서버에서 전송되기 전에 있어야 합니다.
16. ColdFusion의 CORS
웹 서버를 구성할 수 있는 액세스 권한이 없는 경우에도 Coldfusion 스크립트에서 헤더를 보낼 수 있습니다. Coldfusion 스크립트에 다음을 추가한 경우입니다.
태그 기반 파일
<cfheader name="접근-제어-허용-원본" 값="*">
스크립트 기반 파일
var 응답 = getPageContext().getResponse();
response.setHeader("접근-제어-허용-원본","*");참고: 서버에서 출력을 보내기 전에 설정해야 합니다.
17. 톰캣의 CORS
Apache Tomcat에는 CORS에 대한 지원이 포함됩니다(Tomcat 버전 7.0.41부터).
다음은 최소 CORS 구성을 보여주는 문서의 예입니다.
<필터> <filter-name>CorsFilter</filter-name> <filter-class>org.apache.catalina.filters.CorsFilter</filter-class> </필터> <필터 매핑> <filter-name>CorsFilter</filter-name> <url-pattern>/*</url-pattern> </필터 매핑>
18. Virtuoso의 CORS
이러한 인스턴스/서버 수준 설정에는 OpenLink Virtuoso Open Source(VOS) 6.1.3 이상 또는 Virtuoso Commercial Edition 06.02.3129가 필요합니다.
- Virtuoso Conductor 에서 Web Application Server → Virtual Domains & Directories 로 이동합니다.
- 기본 인터페이스 저장소를 확장합니다.
- 새 디렉토리 를 클릭합니다.
- 원하는 가상 디렉터리 유형 을 지정하거나 템플릿으로 사용할 기존 가상 디렉터리를 선택합니다.
- 다음 을 클릭합니다.
- 디렉토리 경로 값을 지정하십시오.
- CORS 옵션을 설정합니다.
- 교차 출처 리소스 공유 – 단일 와일드카드 별표(예:
*) 또는 출처(예:http://example.com:8080또는http://foo.example.com)를 포함합니다. 리소스가 와일드카드를 사용하거나 스크립트 원본을 나열하는 경우 스크립트는 리소스를 검색할 수 있는 권한이 부여됩니다. 이 예의 경우 다음 단일 URI를 입력하십시오.http://demo.openlinksw.com - 의도하지 않은 CORS 거부 확인란 – 선택하고 애플리케이션이 헤더를 덮어쓰지 않는 경우 일치하지 않는 Origins는 빈 응답을 보내 거부됩니다.
- 교차 출처 리소스 공유 – 단일 와일드카드 별표(예:
- 변경 사항 저장 을 클릭합니다.
이전 버전의 Virtuoso의 경우 아래 웹 애플리케이션 수준 지침을 사용할 수 있습니다. 모든 Virtuoso 기반 응용 프로그램은 잘 알려진 HTTP 함수 http_request_header() 및 http_header()를 통해 CORS 검사를 구현할 수 있습니다. 예를 들면 다음과 같습니다.
<?vsp
IF(http_request_header(줄, 'Origin', NULL) = 'http://host.org')
{
http_header('접근-제어-허용-원본: http://host.org\r\n');
}
또 다른
{
반품;
}
-- 여기에 추가 코드 ---
?>
19. WCF의 CORS
WCF 서비스의 경우 새로운 동작을 개발하고 이를 끝점 구성에 포함해야 합니다.
메시지 검사기 만들기
공개 클래스 CustomHeaderMessageInspector : IDispatchMessageInspector
{
사전<문자열, 문자열> requiredHeaders;
public CustomHeaderMessageInspector(Dictionary<string, string> 헤더)
{
requiredHeaders = 헤더 ?? 새로운 사전<문자열, 문자열>();
}
공개 개체 AfterReceiveRequest(참조 System.ServiceModel.Channels.Message 요청, System.ServiceModel.IClientChannel 채널, System.ServiceModel.InstanceContext instanceContext 참조)
{
널 반환;
}
공개 무효 BeforeSendReply(참조 System.ServiceModel.Channels.Message 회신, 개체 상관 상태)
{
var httpHeader = HttpResponseMessageProperty로 응답.Properties["httpResponse"];
foreach(RequiredHeaders의 var 항목)
{
httpHeader.Headers.Add(항목.키, 항목.값);
}
}
}
엔드포인트 동작 생성 및 메시지 검사기를 사용하여 헤더 추가
공개 클래스 EnableCrossOriginResourceSharingBehavior : BehaviorExtensionElement, IEndpointBehavior
{
공개 무효 AddBindingParameters(ServiceEndpoint 끝점, System.ServiceModel.Channels.BindingParameterCollection bindingParameters)
{
}
공개 무효 ApplyClientBehavior(ServiceEndpoint 끝점, System.ServiceModel.Dispatcher.ClientRuntime clientRuntime)
{
}
공개 무효 ApplyDispatchBehavior(ServiceEndpoint 끝점, System.ServiceModel.Dispatcher.EndpointDispatcher 끝점Dispatcher)
{
var requiredHeaders = 새로운 사전<문자열, 문자열>();
requiredHeaders.Add("접근 제어 허용 원본", "*");
requiredHeaders.Add("접근 제어 요청 방법", "POST,GET,PUT,DELETE,OPTIONS");
requiredHeaders.Add("액세스 제어 허용 헤더", "X-요청됨, 콘텐츠 유형");
endpointDispatcher.DispatchRuntime.MessageInspectors.Add(new CustomHeaderMessageInspector(requiredHeaders));
}
public void Validate(ServiceEndpoint 끝점)
{
}
공개 재정의 유형 BehaviorType
{
get { 반환 typeof(EnableCrossOriginResourceSharingBehavior); }
}
보호된 재정의 개체 CreateBehavior()
{
새로운 EnableCrossOriginResourceSharingBehavior() 반환;
}
}
web.config에 새 동작 등록
<확장>
<behaviorExtensions>
<추가 이름="crossOriginResourceSharingBehavior" type="Services.Behaviours.EnableCrossOriginResourceSharingBehavior, 서비스, 버전=1.0.0.0, 문화=중립" />
</behaviorExtensions>
</확장자>
끝점 동작 구성에 새 동작 추가
<endpointBehaviors>
<동작 이름="jsonBehavior">
<웹Http />
<crossOriginResourceSharingBehavior />
</행동>
</endpointBehaviors>
엔드포인트 구성
<endpoint address="api" binding="webHttpBinding" behaviorConfiguration="jsonBehavior" 계약="Service.IServiceContract" />
CORS를 지원하는 API
- 아마존 S3
- DBpedia 스포트라이트
- 드롭박스 API
- 페이스북 그래프 API
- 플리커 API
- 포스퀘어 API
- 구글 API
- 구글 클라우드 스토리지
- GitHub v3 API
- 미디어위키 API
- 접두사.cc
- 내 데이터 게시
- 같은
- 사운드클라우드 API
- 스포티파이 조회 API
- 선라이트 콩그레스 API
- URI버너
- YouTube API(블로그 게시물)
- 문서 API
CORS 구현을 위한 라이브러리
- CORS 필터, Java 웹 애플리케이션용
- cors-python, Python 웹 앱용
- Google AppEngine의 정적 콘텐츠에 CORS를 활성화합니다.
- RDF::LinkedData 버전 0.16 이상
- cors-filter: eBay Software Foundation의 웹 컨테이너용 서버 측 CORS의 Java 서블릿 필터 구현
- add-cors-to-couchdb: PouchDB와 같은 클라이언트 라이브러리에서 사용하기 위해 CouchDB에 CORS 지원을 추가하는 CLI입니다.
읽어주셔서 감사합니다. 게시하다. 이 튜토리얼이 Cross-Origin Resource Sharing 활성화 에 도움이 되기를 바랍니다.
아래에 의견과 비고를 보내주십시오.
