2017-02-12 7 views
1

Application создает ключ апите на каждый пользователь, то есть процесс выглядит следующим образом:Api Шлюз Api Key немедленного использования при создании давая запрещено

  • функция Lambda создает ключ API и добавляет к плану использования
  • значения ключа Апи возвращаются из функции лямбды
  • ключ Апи затем сразу же используется для вызова конечной точки Шлюза API
  • Запрещенного сообщения возвращается

Если я задерживаю выполнение между созданием ключа api и HTTP-адресом конечной точкой шлюза api (примерно на 5 секунд), то он работает по назначению, но меньше, чем я получаю сообщение об ошибке.

Я подозреваю, что ключ api занимает несколько секунд, чтобы размножаться до конечной точки, но я не могу найти метод AWS API, который правильно дает мне знать, когда он это сделал. Кто-нибудь сталкивался с этой проблемой раньше и как вы ее решали?

Лучшее решение, которое я имею на данный момент, заключается в повторном вызове api с раздвижным таймаутом, пока не пройдет необоснованное количество времени.

+0

Зачем вам нужно использовать ключ мгновенно? – Brody

+0

Почему мне это не нужно мгновенно? Если вызов API возвращает значение ключа api, я бы ожидал, что он сможет быть использован мгновенно или, по крайней мере, вернуться только тогда, когда ключ был полностью доведен до конечных точек. – Deif

ответ

1

How long should I wait after applying an AWS IAM policy before it is valid? не тот же вопрос, но, похоже, он схож по своему основополагающему объяснению - дело не столько в том, что ключ API требует времени, сколько в том, чтобы распространяться и становиться видимым во всех возможных местах, где он может существовать до того, как он будет действителен для любого последующего запроса.

Если эти допущения верны, нет механизма для достоверного определения того, готов ли ключ к использованию или нет, поскольку в течение некоторого периода времени после того, как запрос на создание ключа завершается успешно, он находится в ситуации, возможно напоминающей кошку Шредингера, - ключ существует и не существует - вы не знаете, пока не попробуете его, и (в отличие от кошки) даже успешный тест не обязательно докажет, что он полностью готов к использованию из-за возможности (однако маловероятно) результата, такого как fail fail fail fail fail pass pass pass pass. Таково характерное поведение многих широкомасштабных распределенных систем.


Из комментариев:

Если вызов API возвращает значение ключа апи, то я ожидал бы, чтобы иметь возможность использовать немедленно или, по крайней мере, вернуть только тогда, когда ключ был полностью распространяется до конечных точек.

Это имеет смысл на поверхности, но это становится проблематичным в реализации. Что делать, если одна из конечных точек не работает, отключена для обслуживания или в середине восстановления после сбоя и отставания ... что тогда? Не удалось выполнить запрос? Задержать ответ, ожидающий чего-то статистически маловероятного для вас?

Ресурсная стоимость наблюдения за репликацией имеет тенденцию перевесить преимущества во многих случаях и может дестабилизировать плоскость управления системы, если проблема репликации вызывает достаточное отставание и часто не выполняется, за исключением случаев, когда она имеет высокую ценность , , а именно:GetChange action in Route 53, который позволяет проверять распространение изменений через систему - и обратите внимание, что даже в этом случае сам запрос на изменение выполняется без ожидания - если вам нужно проверить состояние синхронизации, вы должны спросить отдельно.

+1

Спасибо за ответ. Это заставило меня понять, что мне нужно учитывать потенциал неудач после успеха! – Deif

0

Многие услуги AWS требуют времени для создания. Обычно есть способ определить, выполнено ли задание. В этом случае похоже, что вы получаете запрещенный ответ до тех пор, пока не будет создан ключ.

Думаю, вам придется обращаться с этим в своем клиенте.

+0

Я понимаю, что это не очень помогает. Извини за это. Если бы вы могли объяснить, почему вам нужно так срочно войти, возможно, будет больше помощи. – Brody