Cross-Domain-Problem :: mit aws ec2, s3 und cloudfront

Question

Das Produkt ist E-Learning LMS - gehostet auf Amazon ec2 Server und der Inhalt (Videos, Scorm-Pakete) würde von s3 Server serviert werden.

Der Link für LMS EC2 ist zu sagen: myname.company-name.com Der Link für s3 Eimer sagen: s3-name.company-name.com

Scorm Pakete von s3-Server dienen soll aber Aufgrund von Einschränkungen der Domänengrenzen (Browser) wird die Kommunikation der Scorm-APIs über das HTML-Frame-Element eingeschränkt. (sogar mit Iframe-Element versucht)

Gibt es eine Möglichkeit, s3 Bucket-Name (cname) oder cloudfront cname zu konfigurieren, so dass über dem Zweck erfüllt ist.

HINWEIS: Selbst wenn wir anbrachten s3 mit Cloudfront Verteilung sagen: s3 Eimer Namen Cloudfront url (AWS-Format): .cloudfont.net und versucht cname zu geben Verteilung zu gleichen wie EC2-Instanz Namen Cloudfront

jedoch , ec2-Dateien Host-Server-Side-Scripting, Entwicklungscode und alle Inhalte über s3 bedient. Daher kann der gesamte ec2-Pfad nicht zur Cloudfront cname oder s3 umgeleitet werden.

Die Content-URLs nur s3-name.company-name.com sollten auf s3 nicht alle ec2-Instanzdateien an cloudfront cname umgeleitet werden. Gibt es eine Problemumgehung mit der Konfiguration der aws-Dienste, so dass Inhalte von s3- und Server-Dateien über das ec2-domänenübergreifende Problem bereitgestellt werden?

HINWEIS: Neben aws Dienste Konfiguration flxibility - das ec Name und s3 Bucketnamen Format oben angegebene ist fix (nicht wechselbar)

Vielen Dank zu machen!

Answer 1

Ich löse gewöhnlich diese Probleme, indem ich die index.html des SCO auf die Ressourcen auf dem S3 zeige, um die Probleme mit den verschiedenen Domänen zu umgehen. Dadurch kann index.html von Ihrer A-Domäne gehostet werden, um Assets und Ressourcen von Ihrer B-Domäne zu laden und die JavaScript-API für JavaScript weiterhin ordnungsgemäß zu verwenden. Und in der Zwischenzeit werden Sie immer noch die Caching-Vorteile erhalten und möglicherweise sogar gemeinsame Skripts, Bilder und andere Ressourcen freigeben, um Bandbreite zu sparen. ich auch sie so ihre // nicht http (s): // so kann es unabhängig von Protokollen arbeiten. Hinweis: Wenn Sie diese für lokale Dateisystembereitstellungen freigeben, treten Probleme aufgrund von file: // vs // auf. Daher können einige andere Veröffentlichungsoptionen oder die Verwendung einer anderen Art von dynamischem Loader für eine universelle Lösung erforderlich sein.

Alternativ gibt es auch einige IFRAME-Hacks, um das zu umgehen. Es ist etwas, das ich normalerweise nicht befürworte.

Beide genannten Optionen erfordern in der Regel eine erneute Bereitstellung, Sie haben jedoch wesentlich kleinere SCOs. Eine imsmanifest.xml mit einer einzigen index.html vs allen Ordnern und Dateien.