0

У меня есть API шлюза конечной точки в какой-то URL, например:Нт AWS API шлюза конечных точек с GET параметрами

https://api.myapp.com/myendpoint 

Люди и/или услуги, которые собираются получать доступ к этой конечной точке необходимо пройти определенные параметры и значения для конечной точки. Как это:

https://api.myapp.com/myendpoint?token=123456 

Можно ли ограничить доступ к конечной точке, если параметр token отсутствует или если значение token не является специфическим заранее определенное значение? Могу ли я настроить свою конечную точку, чтобы просто игнорировать вызовы, у которых нет соответствующего токена?

Я планирую использовать Лямбду как бэкэнд. Должен ли я иметь дело с этим в своей функции лямбда? В конечном счете, я стараюсь избегать ненужных затрат на использование Лямбды и API-шлюза случайными лицами, делающими фиктивные звонки на конечную точку. Поэтому, если у меня есть API-шлюз, просто игнорируйте эти вызовы, не откручивая Лямбду, что было бы идеальным.

Если у меня есть API-шлюз, игнорируйте эти вызовы, я все равно получаю счет за использование, когда фиктивные вызовы совершаются с конечными точками (точками), которые пропускают токен?

Причина, по которой я спрашиваю, заключается в том, что сторонняя служба, которая собирается получить доступ к этой конечной точке, не имеет параметров для передачи параметров аутентификации в заголовках или с использованием AWS Cognito и т. Д. Поэтому я просто пытаюсь думать о простой способ ограничить доступ.

+0

Помогает ли сторонняя служба указать путь? Интересно, можно ли сделать маркер как часть пути. –

+0

Я ничего не вижу в документации, которая действительно привела бы вас к вашей конечной цели. Они, по-видимому, только поддерживают стратегии, основанные на заголовках. Идея пути может работать, делая ваш токен похожим на ресурс, но это действительно не дает вам большой ценности. И снова я не уверен, что параметр query_string обеспечит большую ценность/безопасность. Так что, возможно, раннее возвращение из вашего лямбда-процесса - ваш лучший выбор, учитывая ваши ограничения. Это, по крайней мере, сэкономит вам некоторые затраты лямбда. Возможно, вы хотите удвоить/утроить сервис, чтобы узнать, поддерживают ли они заголовки или сертификаты SSL. –

+0

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

ответ

0

Вам необходимо выполнить эту проверку в Лямбда.

Если у вас есть отображение для параметра запроса token к интеграции конечной точки, то для запроса как ...?token=123 API шлюз будет передать параметр в конечную точку, но для ...?token=, API шлюз не будет.

API-шлюз не выполняет проверку параметров запроса, как вы хотите, и вам будет выставлен счет за запросы.

+0

Вы говорите, что можете использовать сопоставление, чтобы установить API-шлюз на запрос '? Token = 123' в запросе, чтобы игнорировать такое изменение, как'? Token = abc'? –

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