2016-11-21 3 views
0

Это скорее технический вопрос, чем любой связанный код. У меня есть приложение expressjs, работающее на api-gateway с использованием aws-serverless-express wwhich позволяет вам подключить приложение expressjs с минимальными изменениями на api-gateway. Но поскольку APIG генерирует URL-адрес для каждого развертывания api, с идентификатором api-id, это не является дружественным к клиенту. Поэтому я настроил дистрибутив cloudfront, указав URL-адрес APIG.aws apigateway cloudfront expressjs приложение всегда отображает api-gateway url

Однако, когда я запускаю приложение, URL-адрес, отображаемый в браузере, не тот, который создается облачным (хотя я использую этот URL-адрес для входа в приложение), но тот, который был создан APIG.

Я знаю, что в APIG есть опция для установки пользовательского имени домена, и после проведения некоторых исследований APIG устанавливает распределение Cloudfront в фоновом режиме, но поскольку я не был настройкой службы DNS и не имеют прав на изменение этих параметров для этой конкретной роли/региона на aws, задавалось вопросом, связана ли проблема с тем, что пользовательский URL не был настроен с помощью параметров APIG?

+0

Вы пытались настроить запись CNAME в своем DNS, указывая на URL-адрес шлюза API ? – barudo

+0

Yeap, в настоящее время это то, что настроено. – hyprstack

+0

hmmm ... ok, так что у вас нет доступа к вашему DNS ... tsk tsk .... – barudo

ответ

1

Если вы введете правильный URL-адрес в адресную строку браузера и нажмите ENTER, отобразится эта страница. URL-адрес в адресной строке браузера может измениться, если сервер отправляет код статуса перенаправления (301, 302, 307 и т. Д.).

Чтобы отладить это, откройте веб-инспектор в своем браузере, выберите вкладку «Сеть» и следуйте HTTP-запросам. Если вы видите статус перенаправления, загляните в заголовки, чтобы узнать, какая система отправила его.

EDIT: API Gateway отправляет 301 для перенаправления на HTTPS, если к нему обращается CloudFront через HTTP. Это, кажется, проблема здесь. Как указывалось в другом ответе, принудительное использование CloudFront для доступа к шлюзу API через HTTPS-only устраняет эту проблему.

+0

Если он делает перенаправление, он делает это за кулисами и не то, что я не хочу изменять. Действительно, есть статус переадресации (301), когда запрос сначала отправляется на облачную инфраструктуру и имеет заголовок местоположения, установленный на URL-адрес apigateway. Глядя на инструменты chrome: // net-internals, особенно на вкладку DNS, мне показана служба DNS для моего URL-адреса облака и одна для URL-адреса apigateway. Является ли это предположением, что у меня есть служба DNS, вызывающая другую службу DNS? – hyprstack

+0

Если у вас есть 301, то DNS не является вашей проблемой. DNS подобен телефонной книге: если вы знаете имя (например, www.example.com), ваш браузер использует DNS для поиска номера IP-адреса этой службы. Затем браузер соединяется с («вызывает») этот номер. И 301 - это в основном сервер («человек») на другом конце, говорящий вам позвонить кому-то еще. Поэтому, если ваше начальное соединение переходит к CloudFront, вам нужно отследить оттуда, который отправляет 301. Поскольку CloudFront и Gateway API не регулярно отправляют 301s другим сервисам, ваше экспресс-приложение является хорошим кандидатом для просмотра. (Отключите приложение, чтобы доказать это.) – Digitalkapitaen

+0

спасибо, что нашли время, чтобы опубликовать объяснение и возможное решение. Однако это была конфигурация DNS, которая была проблемой, как объяснялось в моем ответе ниже. – hyprstack

2

Нашли правильный ответ здесь в другом SO question!

По существу, необходимо было изменить несколько настроек в облачном режиме.

Проверено, что «Политика протокола просмотра» на моем дистрибутиве CloudFront была настроена либо «Перенаправить HTTP на HTTPS», либо «Только HTTPS» и установить «Протокол происхождения протокола» на «Только HTTPS».

Это, казалось, исправить проблему для меня.

0

Я бы посоветовал не устанавливать распределение CF, указывающее на конечную точку вашего шлюза API. API Gateway уже включает дистрибутив CF. Если у вас уже есть имя домена и сертификат, вы можете легко импортировать его в API-шлюз напрямую с помощью функции «Пользовательское доменное имя»: http://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-custom-domains.html

+0

Причина, по которой люди, например, помещают облачный оперу впереди apigateway, заключается в том, что apigateway не имеет поддержки для диспетчера сертификатов, где это делает cloudfront. Еще меньше дел. Он также позволяет вам иметь ваш статический контент и api (example.com/api) в одном URL-адресе и не иметь дело с CORS. Это говорит о том, что это работает только для общедоступных веб-сайтов, которые не используют аутентификацию IAM. – Atifm

Смежные вопросы