Problème de domaine croisé :: avec aws ec2, s3 et cloudfront

Question

Le produit est un système d'apprentissage en ligne (LMS) - hébergé sur le serveur amazon ec2 et le contenu (vidéos, paquets scorm) serait servi depuis le serveur s3.

Le lien pour LMS EC2 est de dire: myname.company-name.com Le lien pour seau s3 est dit: s3-name.company-name.com

paquets SCORM veulent servir de serveur, mais s3 En raison des restrictions inter-domaines (navigateur) restreint les API scorm pour communiquer via l'élément de cadre HTML. (même essayé avec l'élément iframe)

Existe-t-il un moyen de configurer le nom du compartiment s3 (cname) ou cloudfront cname afin que ce but soit atteint.

REMARQUE: Même si nous attachions s3 avec distribution CloudFront dire: nom de seau s3 à url CloudFront (format AWS): .cloudfont.net et essayer de donner cname à la distribution CloudFront à même que le nom de l'instance EC2

Cependant , les fichiers ec2 script côté serveur hôte, le code de développement et tout le contenu servi via s3. Donc, je ne peux pas rediriger tout le chemin ec2 vers cloudfront cname ou s3.

Les URL de contenu comme s3-name.company-name.com uniquement, doivent être redirigées vers s3 et non pas tous les fichiers d'instance ec2 vers cloudfront cname. Existe-t-il une solution de contournement avec la configuration des services aws pour que le contenu soit diffusé à partir des fichiers s3 et serveur via le problème d'adressage croisé ec2?

REMARQUE: en dehors de la configuration des services aws flxibility - le format du nom du godet de nom et s3 ec donnée ci-dessus est de rendre fixe (non modifiable)

Un grand merci!

Answer 1

Je résous couramment ces problèmes en pointant le index.html du SCO vers les ressources sur le S3 pour contourner les problèmes inter-domaines que vous rencontrez. Cela permet au fichier index.html hébergé à partir de votre domaine A de charger des ressources et des ressources de votre domaine B et de permettre à l'API JavaScript JavaScript de continuer à fonctionner correctement. Et en attendant, vous bénéficierez des avantages de la mise en cache et pourrez même partager des scripts, des images et d'autres ressources courantes pour économiser de la bande passante. Je les parcours aussi // donc pas http (s): // donc il peut fonctionner indépendamment des protocoles. Notez que si vous les publiez pour des déploiements de système de fichiers locaux, vous rencontrerez des problèmes liés à la commande file: // vs //. Ainsi, d'autres options de publication ou l'utilisation d'un autre type de chargeur dynamique peuvent être nécessaires pour une solution unique.

Il existe également des hacks IFRAME pour contourner ce problème. C'est quelque chose que je ne préconise généralement pas cependant.

Les deux options mentionnées nécessitent généralement un redéploiement, mais les SCO sont beaucoup plus petites. Un imsmanifest.xml avec un seul index.html par rapport à tous les dossiers et fichiers.