Проблема с перекрестным доменом :: с aws ec2, s3 и облачным

Question

Продукт представляет собой электронное обучение LMS, размещенное на сервере amazon ec2, и контент (видео, пакеты scorm) будет обслуживаться с сервера s3.

Ссылка для LMS EC2, это сказать: myname.company-name.com Ссылка для s3 ведро говорят: s3-name.company-name.com

SCORM пакеты хотят служить от s3 сервера, но из-за ограничений кросс-домена (браузер) ограничивает API-интерфейсы scorm для связи через элемент фрейма HTML. (даже пробовал с элементом iframe)

Есть ли способ настроить имя байта s3 (cname) или облачное имя cname, чтобы выполнить эту цель.

ПРИМЕЧАНИЕ: Даже если мы прикрепили s3 с распределением CloudFront говорят: s3 имя ведро CloudFront URL (формат AWS): .cloudfont.net и попытаться дать CNAME для CloudFront распределения в такой же, как имя ec2 экземпляра

Однако , скрипты на стороне сервера сервера ec2, код разработки и весь контент, обслуживаемый через s3. Таким образом, can not перенаправляет весь путь ec2 к облачному cname или s3.

URL-адреса контента, такие как s3-name.company-name.com, должны быть перенаправлены на s3 не все файлы экземпляров ec2 в облачный cname. Существует ли обходное решение с конфигурацией aws-сервисов, чтобы контент был передан из файлов s3 и server через проблему перекрестного доступа через ec2?

Примечание: кроме AWS конфигурации услуги flxibility - ЕС имя и s3 Ковш формат имени приведенный выше, чтобы исправить (не изменяемый)

Большое спасибо!

Answer 1

Я обычно решаю эти проблемы, указывая index.html SCO на ресурсы на S3, чтобы обойти проблемы с перекрестным доменом, которые у вас есть. Это позволяет index.html размещаться из вашего домена A, загружать активы и ресурсы из вашего домена B и позволяет JavaScript JavaScript JavaScript работать исправно. И в то же время вы все равно получите преимущества кэширования и, возможно, даже совместное использование общих сценариев, изображений и других активов для экономии полосы пропускания. Я также направляю их так, чтобы он не был http (s): // поэтому он может работать независимо от протоколов. Обратите внимание, что если вы когда-нибудь выпустите их для локальных развертываний файловой системы, у вас возникнут проблемы из-за файла: // vs //. Поэтому для решения одного размера для всех требуется несколько других вариантов публикации или использование какого-либо другого динамического загрузчика.

Кроме того, есть некоторые хакеры IFRAME, чтобы обойти это тоже. Однако это то, что я обычно не защищаю.

Оба указанных параметра обычно требуют повторного развертывания, однако в результате у вас намного меньше SCO. Imsmanifest.xml с одним index.html и всеми папками и файлами.