Шлюз API периодически возвращает заголовок «Access-Control-Allow-Origin», когда запрос CORS OPTIONS успешно завершается.

Я в полной растерянности от того, что сейчас происходит. Я часами читаю сообщения об API Gateway CORS, и все они сводятся к одному и тому же основному вопросу. Вы неправильно включили запрос OPTIONS в своем API; то, что я на 99% уверен, что сделал правильно на данный момент.

Я работаю с API-интерфейсом Kestrel, размещенным на Lambda, предоставленным библиотекой Amazon.Lambda.AspNetCoreServer, сопоставленной через шлюз API. В настоящее время он размещен в частной подсети, где он имеет доступ в Интернет через шлюз NAT, все это было протестировано с помощью экземпляров EC2, запущенных в частной подсети. У меня есть шлюз API, работающий на api.example.com, в то время как фактический веб-сайт размещен на example.com через статический хостинг веб-сайтов S3.

CORS был включен как в веб-API Kestrel в классе Startup, так и в сопоставлении шлюза API, оба из которых разрешают все пути. Я изо всех сил пытался принять решение о том, включать ли CORS на уровне шлюза API, поскольку я читал, что с интеграцией прокси шлюза API вы можете просто перенести всю проверку CORS на уровень Lambda, что вместо этого имело бы смысл дублирования проверки CORS в двух разных местах (API Gateway и Web API).

Из моего веб-клиента я могу без проблем делать запросы к API большую часть времени. Похоже, что когда я даю ему достаточно времени, последующие запросы обречены на провал. Я запускаю «активационный» вызов Lambda, когда пользователь попадает на страницу, чтобы предотвратить длительную загрузку любых последующих действий. Это должно гарантировать, что пользователь работает с горячей лямбдой или замороженной лямбдой вместо холодной лямбды. Кажется, что проблема возникает через несколько минут, и предыдущий экземпляр лямбды может больше не существовать.

Если я загружаю страницу, лямбда должна быть активирована. Если я даю ему немного времени, а затем пытаюсь отправить контактную информацию, я обычно получаю отказ в запросе. Консоль разработчика указывает, что ошибка возникла из-за «Нет заголовка« Access-Control-Allow-Origin »..."; тем не менее, есть определенные моменты, когда я вижу передачу запроса опций, но ошибочный ответ не содержит заголовка access-control-allow-origin.

Я в полной растерянности, если кто-нибудь еще может помочь объяснить несоответствие, которое я вижу, это было бы очень признательно. Это было бы в миллион раз проще, если бы Lambda перестала вызывать ошибки языка C в CloudWatch в моем приложении C#. Я очень разочаровываюсь в Lambda и начинаю думать о переходе на альтернативные методологии хостинга.


person I. Buchan    schedule 03.04.2017    source источник


Ответы (1)


Хотя мой ответ был относительно быстрым, этот пост был последней попыткой после нескольких дней исследований. Оказывается, проблема на самом деле не связана с CORS, а связана с использованием асинхронного контекста в классе Startup.cs.

Сбой, о котором был этот вопрос, был конкретно связан с асинхронным методом POST. Это приложение все еще находится на ранней стадии, поэтому у меня было не так много асинхронных методов, с которыми я мог бы поиграть. Я предполагал, что это был отказ более высокого уровня; однако на самом деле это был сбой асинхронного контекста на уровне контроллера.

Я попытался использовать асинхронный метод в классе Startup.cs, чтобы помочь с инициализацией службы Singleton. Использование Task.WaitAll в этом классе запуска уничтожило асинхронный контекст для всего приложения. Оказывается, любые попытки ожидания асинхронного вызова приведут к сбою. В конце концов, все это связано с использованием асинхронного метода в моем классе запуска.

Как только я удалил свой асинхронный метод запуска, я смог без проблем использовать свой API. Сбой, который периодически возникал во время заполнения метода CORS, был вызван сбоем асинхронного контекста; однако, поскольку это произошло при запросе метода OPTIONS, он приписал сбой CORS.

Урок дня: если вы хотите создать экземпляр API Kestrel в микросервисе Lambda с помощью пакета Amazon.Lambda.AspNetCoreServer, ЛУЧШЕ НЕ ИСПОЛЬЗОВАТЬ ASYNC ИЛИ TASK IN Startup.cs

person I. Buchan    schedule 04.04.2017