tyk
tyk copied to clipboard
[TT-10522] Update Key API doesn't work as documented
Branch/Environment/Version
- Branch/Version: 1.5.1
- Environment: On-prem
Describe the bug The API example from https://tyk.io/docs/tyk-gateway-api/ doesn't work
Reproduction steps Add a key then try to update it
$ $ curl -X PUT -H "x-tyk-authorization: foo" -s -H "Content-Type: application/json" -d '{ "quota_max": 60,
"quota_renews": 1406121006,
"quota_renewal_rate": 60,
"allowance": 100,
"rate": 100,
"per": 5,
"org_id": "53ac07777cbb8c2d53000002"
}' http://localhost:8080/tyk/keys/9dfafcb4?hashed=true
{"status":"error","message":"Failed to create key, ensure security settings are correct."}
Actual behavior
Request fails with
{"status":"error","message":"Failed to create key, ensure security settings are correct."}
Message appears in the log:
level=error msg="Master keys disallowed in configuration, key not added."
Expected behavior Key is updated
Configuration (tyk config file): https://github.com/TykTechnologies/tyk-gateway-docker
Hi @jakub-bochenski,
Thanks for trying Tyk!
Have you provided the correct authorization secret (the one you set as secret
in your tyk.conf
file) in the x-tyk-authorization
header of your API request?
Yes I did
Thanks - I'll get one of the team to take a look, to work out why it's not working for you.
@jakub-bochenski it looks like the payload you're using doesn't contain any access rights, and that's maybe because you want to use this key to access all APIS? If so, for this case allow_master_keys
gateway configuration option needs to be enabled.
More information here: https://tyk.io/docs/tyk-oss-gateway/configuration/#allow_master_keys
Let us know if this works for you, Thank you
@lghiur no, I just wanted to change some settings of the key, without changing the access rights
Is it possible to do it? Or do I have to specify all values again? I thought the documentation showed a partial update is possible.
Having to specify all values is inconvenient. If you have two people modifying the key concurrently it will result in lost updates (unlike a patch approach)
@jakub-bochenski at the moment you need to provide all the access rights again, otherwise we assume that you want access to all APIs as mentioned above.
What you describe it would work more within a PATCH request indeed, but that's not supported atm.
OK, thanks for the clarification.
You might want to update the example in the API Docs, as I think it's misleading now
@jakub-bochenski thanks, I will open an internal ticket for improving docs.