We are facing an issue with api keys. This is happening randomly. Sometimes, when calling the api, we get error: “key is not authorized”. So we regenerate another key for the api.
Do you think that existing keys get expired upon a specific change in the api? I’m not sure why this happens.
Are you setting expiry explicitly in Tyk?
When you generate a key in Tyk Cloud using the interface, the expiry for that token is set to 1 hour by default in the interface unless you change it:
Also, if you set an expiry in the policy that is attached to your catalog entry, it will expire the key on create:
Lastly, if you are using Hybrid out of the box, the redis that comes installed with that container is just a cache, it is volatile and will return to Tyk Cloud to get key data if it can’t find a reference there, which can happen if you restart the container.
It could be any of those things.
Please let me understand correctly.
1- If we restart the container, then we make an api request and we pass a correct key.
2- The Hybrid will not find the key in its cache and it will try to fetch from tyk cloud.
Should we get in this case a “Key not authorized” error?
I’m a little bit confused.
Yes, because the key can;t be found it is not authorized (the error log will show the real reason, but we do not expose this to the end user).
Is there a way in hybrid config to make it rebuild its cache from tyk cloud whenever it gets restarted.
We need to avoid getting this error when the hybrid restarts.
No, the containers are meant to be indempotent and not retain state, instead, use an external Redis DB and then the cache will survive a restart.
i do believe your error is down to a key expiring not a cache miss, as it would have been back-filled from cloud.