Cross domain issue :: with aws ec2 , s3 and cloudfront

Question

The product is elearning LMS - hosted on amazon ec2 server and the content (videos, scorm packages ) would be served from s3 server.

The link for LMS EC2 is say: myname.company-name.com The link for s3 bucket is say: s3-name.company-name.com

Scorm packages want to serve from s3 server but because of cross domain restrictions (browser) restricts the scorm APIs to communicate via HTML frame element. (even tried with iframe element)

Is there a way to configure s3 bucket name (cname) or cloudfront cname so that above purpose is fulfilled.

NOTE: Even if we attached s3 with cloudfront distribution say: s3 bucket name to cloudfront url (AWS format): .cloudfont.net and try to give cname to cloudfront distribution to same as ec2 instance name

However, ec2 files host server side scripting , development code and all content served via s3. So, cant redirect all the ec2 path to cloudfront cname or s3.

The content urls like s3-name.company-name.com only, should be redirected to s3 not all ec2 instance files to cloudfront cname. Is there a workaround with aws services configuration so that content is served from s3 and server files via ec2 addressing cross domain issue?

NOTE: apart from aws services configuration flxibility - the ec name and s3 bucket name format given above is to make fix (not changeable)

Many thanks!

Answer 1

I commonly solve these issues by pointing the index.html of the SCO to the resources on the S3 to get around the cross domain issues you're having. This allows the index.html being hosted from your A domain, to load assets and resources from your B domain and lets the JavaScript to JavaScript API continue to work properly. And in the mean time you'll still gain the caching benefits and possibly even sharing common scripts, images and other assets to save bandwidth. I also path them so its // not http(s):// so it can work independent of protocols. Note, if you ever release these for local file system deployments you'll have issues due to file:// vs //. So some other publishing options or using some other sort of dynamic loader may be required for a one-size-fits-all solution.

Alternatively, there are some IFRAME hacks to get around this too. It's something I typically don't advocate however.

Both options mentioned typically require re-deploying however you have much smaller SCOs as a result. A imsmanifest.xml with a single index.html vs all the folders and files.