원본 간 리소스 공유 이해(CORS)

Adobe Experience Manager의 원본 간 리소스 공유(CORS)는 비 AEM 웹 속성을 사용하여 클라이언트측을 호출하여 인증되거나 인증되지 않은 AEM을 모두 호출하여 콘텐츠를 가져오거나 AEM과 직접 상호 작용할 수 있도록 합니다.

Adobe Granite 원본 간 리소스 공유 정책 OSGi 구성

CORS 구성은 AEM에서 OSGi 구성 팩토리로 관리되며 각 정책은 팩토리의 하나의 인스턴스로 표시됩니다.

• http://<host>:<port>/system/console/configMgr > Adobe Granite Cross Origin Resource Sharing Policy

Adobe Granite Cross-Origin Resource Sharing Policy (com.adobe.granite.cors.impl.CORSPolicyImpl)

정책 선택

정책을 선택하려면

• Allowed Origin (으)로 Origin 요청 헤더
• 및 Allowed Paths 요청 경로 포함.

이 값과 일치하는 첫 번째 정책이 사용됩니다. 찾을 수 없는 경우 CORS 요청이 거부되었습니다.

구성된 정책이 없으면 CORS 서버의 다른 모듈이 응답하지 않는 한 핸들러가 비활성화되어 효과적으로 거부되므로 요청에 대한 응답도 이루어지지 않습니다. CORS.

정책 속성

허용된 원본

• "alloworigin" <origin> | *
• 목록 origin 리소스에 액세스할 수 있는 URI를 지정하는 매개 변수입니다. 자격 증명이 없는 요청의 경우 서버에서 다음을 지정할 수 있습니다. * 를 와일드카드로 만들기 때문에 모든 원본이 리소스에 액세스할 수 있습니다. 를 사용하지 않는 것이 좋습니다 Allow-Origin: * 프로덕션 환경에서는 모든 외국(즉, 공격자) 웹 사이트에서 CORS가 없는 것은 브라우저에서 엄격히 금지된다는 요청을 할 수 있기 때문입니다.

허용된 원본 (Regexp)

• "alloworiginregexp" <regexp>
• 목록 regexp 리소스에 액세스할 수 있는 URI를 지정하는 정규 표현식. 정규 표현식은 신중하게 작성되지 않으면 의도하지 않은 일치로 이어질 수 있으므로 공격자가 정책과 일치하는 사용자 정의 도메인 이름을 사용할 수 있습니다. 일반적으로 를 사용하여 각 특정 원본 호스트 이름에 대해 별도의 정책을 사용하는 것이 좋습니다. alloworigin를 조정할 경우 다른 정책 속성이 반복적으로 구성된 경우에도 마찬가지입니다. 서로 다른 기원은 서로 다른 수명 주기와 요구 사항을 갖는 경향이 있으므로 명확한 분리로부터 이익을 얻을 수 있다.

허용되는 경로

• "allowedpaths" <regexp>
• 목록 regexp 정책이 적용되는 리소스 경로를 지정하는 정규 표현식.

노출된 헤더

• "exposedheaders" <header>
• 브라우저가 액세스할 수 있는 요청 헤더를 나타내는 헤더 매개 변수 목록입니다.

최대 나이

• "maxage" <seconds>
• A seconds 프리플라이트 요청의 결과가 캐시될 수 있는 기간을 나타내는 매개 변수.

지원되는 헤더

• "supportedheaders" <header>
• 목록 header 실제 요청을 수행할 때 사용할 수 있는 HTTP 헤더를 나타내는 매개 변수입니다.

허용된 메서드

• "supportedmethods"
• 실제 요청을 수행할 때 사용할 수 있는 HTTP 메서드를 나타내는 메서드 매개 변수 목록입니다.

자격 증명 지원

• "supportscredentials" <boolean>
• A boolean 요청에 대한 응답을 브라우저에 노출할 수 있는지 여부를 나타냅니다. 프리플라이트 요청에 대한 응답의 일부로 사용되는 경우 자격 증명을 사용하여 실제 요청을 수행할 수 있는지 여부를 나타냅니다.

예제 구성

사이트 1은 익명으로 액세스할 수 있는 기본 읽기 전용 시나리오로, 콘텐츠를 GET 요청:

{
  "supportscredentials":false,
  "exposedheaders":[
    ""
  ],
  "supportedmethods":[
    "GET",
    "HEAD",
    "OPTIONS"
  ],
  "alloworigin":[
    "http://127.0.0.1:3000",
    "https://site1.com"

  ],
  "maxage:Integer": 1800,
  "alloworiginregexp":[
    "http://localhost:.*"
    "https://.*\.site1\.com"
  ],
  "allowedpaths":[
    "/content/_cq_graphql/site1/endpoint.json",
    "/graphql/execute.json.*",
    "/content/site1/.*"
  ],
  "supportedheaders":[
    "Origin",
    "Accept",
    "X-Requested-With",
    "Content-Type",
    "Access-Control-Request-Method",
    "Access-Control-Request-Headers",
  ]
}

사이트 2는 보다 복잡하며 승인 및 변경(POST, PUT, DELETE) 요청이 필요합니다.

{
  "supportscredentials":true,
  "exposedheaders":[
    ""
  ],
  "supportedmethods":[
    "GET",
    "HEAD"
    "POST",
    "DELETE",
    "OPTIONS",
    "PUT"
  ],
  "alloworigin":[
    "http://127.0.0.1:3000",
    "https://site2.com"

  ],
  "maxage:Integer": 1800,
  "alloworiginregexp":[
    "http://localhost:.*"
    "https://.*\.site2\.com"
  ],
  "allowedpaths":[
    "/content/site2/.*",
    "/libs/granite/csrf/token.json",
  ],
  "supportedheaders":[
    "Origin",
    "Accept",
    "X-Requested-With",
    "Content-Type",
    "Access-Control-Request-Method",
    "Access-Control-Request-Headers",
    "Authorization",
    "CSRF-Token"
  ]
}

Dispatcher 캐싱 관련 사항 및 구성

Dispatcher 4.1.1 이상 응답 헤더를 캐시할 수 있습니다. 이를 통해 캐싱할 수 있습니다 CORS 를 따라 헤더 표시 CORS- 요청이 익명으로 되어 있는 한 요청된 리소스입니다.

일반적으로 Dispatcher에서 콘텐츠를 캐시하기 위한 동일한 고려 사항은 Dispatcher에서 CORS 응답 헤더를 캐시하는 데 적용할 수 있습니다. 다음 표는 다음과 같은 시점을 정의합니다 CORS 헤더(따라서 CORS 요청)을 캐시할 수 있습니다.

CORS 헤더의 캐싱을 허용하려면 지원하는 모든 AEM Publish dispatcher.any 파일에 다음 구성을 추가하십시오.

/myfarm {
  ...
  /headers {
      "Origin"
      "Access-Control-Allow-Origin"
      "Access-Control-Expose-Headers"
      "Access-Control-Max-Age"
      "Access-Control-Allow-Credentials"
      "Access-Control-Allow-Methods"
      "Access-Control-Allow-Headers"
  }
  ...
}

다음을 잊지 마십시오. 웹 서버 응용 프로그램을 다시 시작합니다. 을(를) 변경한 후 dispatcher.any 파일.

다음 요청 시 헤더가 적절하게 캐시되도록 하려면 캐시를 완전히 지워야 할 수 있습니다. /cache/headers 구성 업데이트.

CORS 문제 해결

로깅은 다음에서 사용할 수 있습니다. com.adobe.granite.cors:

• 활성화 DEBUG 이(가) 왜 CORS 요청이 거부되었습니다.
• 활성화 TRACE CORS 핸들러를 거치는 모든 요청에 대한 세부 정보 보기

팁:

• curl을 사용하여 XHR 요청을 수동으로 다시 생성하지만, 각 헤더 및 세부 정보가 다를 수 있으므로 모든 헤더와 세부 정보를 복사해야 합니다. 일부 브라우저 콘솔에서는 curl 명령을 복사할 수 있습니다.
• 인증, CSRF 토큰 필터, Dispatcher 필터 또는 기타 보안 레이어가 아닌 CORS 핸들러에서 요청이 거부되었는지 확인합니다.
  • CORS 처리기가 200으로 응답하면 Access-Control-Allow-Origin 헤더에 응답이 없습니다. 로그에서 거부 여부를 검토하십시오. DEBUG 위치: com.adobe.granite.cors
• 의 Dispatcher 캐싱인 경우 CORS 요청이 활성화됨
  • 다음을 확인합니다. /cache/headers 구성이에 적용됩니다. dispatcher.any 웹 서버가 다시 시작되었습니다.
  • OSGi 또는 dispatcher.any 구성을 변경한 후 캐시가 제대로 지워졌는지 확인하십시오.
• 필요한 경우 요청에 대한 인증 자격 증명이 있는지 확인합니다.

지원 자료

• 원본 간 리소스 공유 정책을 위한 AEM OSGi 구성 팩토리
• 원본 간 리소스 공유(W3C)
• HTTP 액세스 제어(Mozilla MDN)

Business.Adobe.com 리소스

Auto Form Fill Personalized Experiences Managed Cloud Version History Dynamic Forms Digital Rights Management