크로스 도메인 문제 :: aws ec2, s3 및 클라우드 프론트로

Question

이 제품은 아마존 ec2 서버에서 호스팅되는 eLearning LMS이며 콘텐츠 (비디오, 스톰 패키지)는 s3 서버에서 제공됩니다.

는 LMS EC2에 대한 링크가 말할 수 있습니다 : myname.company-name.com S3 버킷에 대한 링크가 말한다 : s3-name.company-name.com

SCORM 패키지 S3 서버에서 제공하고 싶지만 교차 도메인 제한 (브라우저)으로 인해 HTML 프레임 요소를 통해 통신하도록 스톰 API가 제한됩니다. (심지어 iframe 요소로 시도)

위의 목적을 달성 할 수 있도록 s3 버킷 이름 (cname) 또는 cloudfront cname을 구성하는 방법이 있습니까?

참고 : CloudFront를 URL에 S3 버킷 이름 (AWS 형식) : 우리가 부착 된 경우에도 CloudFront를 분포 S3 말 .cloudfont.net 및

그러나 EC2 인스턴스 이름으로 동일하게 분포를 CloudFront를하는 CNAME을 제공하려고 , ec2 파일은 호스트 서버 측 스크립팅, 개발 코드 및 s3을 통해 제공되는 모든 컨텐츠를 포함합니다. 따라서, 모든 ec2 경로를 cloudname cname 또는 s3으로 리디렉션 할 수 없습니다.

s3-name.company-name.com과 같은 콘텐츠 URL 만 s3으로 보내야합니다. 모든 ec2 인스턴스 파일이 cloudname cname으로 리디렉션되지 않아야합니다. aws 서비스 구성을 사용하여 해결 방법이 있습니까? 그렇다면 ec2 도메인 간 문제를 통해 s3 및 서버 파일에서 콘텐츠가 제공됩니까?

참고 : 떨어져 AWS 서비스 구성 flxibility에서 - 위의 EC 이름과 S3 버킷 이름 형식은 수정 (변경되지 않음)

많은 감사를하는 것입니다!

Answer 1

저는 일반적으로 SCO의 index.html을 S3의 리소스로 지정하여 문제를 해결합니다. 이렇게하면 A 도메인에서 호스팅되는 index.html이 B 도메인에서 에셋과 리소스를로드 할 수 있고 JavaScript 대 JavaScript API가 계속 제대로 작동 할 수 있습니다. 그 동안 평균 대역폭을 절약하기 위해 캐싱의 이점을 얻고 공통 스크립트, 이미지 및 기타 자산을 공유 할 수도 있습니다. 나는 그것들을 // http가 아닌 // 경로로 가지고 있으므로 프로토콜과 독립적으로 작동 할 수있다. 로컬 파일 시스템 배포를 위해이 파일을 배포 한 경우 file : // vs //로 인해 문제가 발생합니다. 따라서 다른 모든 게시 옵션이나 다른 종류의 동적 로더를 사용하는 것이 원터치 솔루션에 필요할 수 있습니다.

또는 IFRAME 해킹이 있습니다. 그것은 내가 일반적으로 옹호하지 않는 것입니다.

두 옵션 모두 재 전개가 필요하지만 결과적으로 SCO가 훨씬 적습니다. index.html이 하나 인 imsmanifest.xml은 모든 폴더와 파일을 비교합니다.