2

Application creates an api key on a per user basis, meaning the process is as follows:

  • Lambda function creates api key and adds to a usage plan
  • Api key value is returned from lambda function
  • Api key is then immediately used to call an Api Gateway end point
  • Forbidden message is returned

If I delay execution between api key creation and the http request to the api gateway end point (by around 5 seconds), then it works as intended, but less than that I get an error.

I suspect that the api key takes a few seconds to propagate to the endpoint but I can't find an AWS API method that correctly lets me know when it has done so. Has anyone come across this problem before and how did you solve it?

The best solution I have at the moment is to retry the api call on a sliding timeout until an unreasonable amount of time has passed.

DF_
  • 3,743
  • 25
  • 34
  • Why do you need to use the Key instantly? – Brody Feb 13 '17 at 02:36
  • Why wouldn't I need it instantly? If an API call returns the api key value then I would expect it to be able to be used instantly, or at least return only when the key has been propagated fully to the end points. – DF_ Feb 13 '17 at 08:55
  • One use case is to create the api key on the fly in the authorizer (that authenticated the request with a JWT header for instances), and associated it with a usage plan. One way to avoid this pb is to have a default api key, in the authorizer, if you have to create the api key, then use the default api key in the policy "usageIdentifierKey". This means the 1rst time a new custom authenticate it uses the default api key, next time (for instance 5 minutes after cache expire) and all the other times it will use his own api key. – jocelyn Apr 03 '23 at 15:32

2 Answers2

1

How long should I wait after applying an AWS IAM policy before it is valid? is not the same question but seems likely to be similar in its underlying explanation -- it's not so much a case of the API key taking time to exist but rather taking time to propagate and become visible at every possible place where it might need to exist before being valid for any subsequent request.

If those assumptions are correct, there is no mechanism for authoritatively determining whether the key is ready for use or not, because for some period of time after the key creation request succeeds, it's in a situation arguably reminiscent of Schrödinger's cat -- the key both exists and doesn't exist -- you don't know until you try it, and (unlike the cat) even a successful test does not necessarily prove that it is fully ready for use, because of the possibility (however unlikely) of a result such as fail fail fail fail pass fail pass pass pass. Such is the characteristic behavior of many large-scale, distributed systems.


From comments:

If an API call returns the api key value then I would expect it to be able to be used instantly, or at least return only when the key has been propagated fully to the end points.

That makes sense on the surface, but it becomes problematic in implementation. What if one of the endpoints is failed, offline for maintenance, or in the middle of recovering from an outage and lagging... what then? Fail the request? Delay the response waiting for something statistically unlikely to impact you?

The resource cost of observing replication tends to outweigh the benefits in many cases and can destabilize the control plane of a system if a replication issue causes a sufficient backlog, and is often not implemented except in cases where it has a high value, viz. the GetChange action in Route 53 which allows you to verify the propagation of a change through the system -- and note that even in this case, the change request itself succeeds without waiting -- if you need to verify the sync state, you have to ask separately.

Community
  • 1
  • 1
Michael - sqlbot
  • 169,571
  • 25
  • 353
  • 427
  • 1
    Thanks for the answer. It made me realise I need to account for the potential of failures after a success too! – DF_ Feb 13 '17 at 14:30
0

A lot of AWS services take time to create. Usually there is a way to detect if the job has been completed. In this case it looks like you get a forbidden response until the key is created.

I think you will have to handle this in your client.

Brody
  • 2,074
  • 1
  • 18
  • 23
  • I realise that this is not a lot of help. Sorry about that. If you could explain why you need to key so urgently there might be more help available. – Brody Feb 13 '17 at 02:40