Failed to update a key using the dashboard API

Imported Google Group message. Original thread at: Redirecting to Google Groups Import Date: 2016-01-19 21:19:51 +0000.
Sender:Richard Hulm.
Date:Tuesday, 11 August 2015 12:51:23 UTC+1.

Hi Guys,

I’m getting a 400 bad request error when using the dashboard API to update a key.

We’re trying to fully automate our deployments, so we’re only using the REST API. For now, I’m getting around it by deleting the key and creating a new one with both access rights, which seems to work OK (but has the disadvantage of forcing the application to get a new token rather than re-using the existing one! Was going to try deleting the key, then using the gateway API directly to create a new key using the same value as the old one, but with new rights)

I’ll detail the steps to reproduce below, hoping you could point out anything I’m doing wrong or if this is a bug? I’ve attached json files representing the requests i’ve made to the API, and then the 6th one receives a 400 bad request saying the api_id must be set

(Gateway is hosted at localhost:5000 and dashboard at localhost:3000)

request_1_create_api.json > Create API that represents service 1

request_2_reload_apis.json > Force a reload of the definitions in the gateway

request_3_first_key_request.json > Creates a key that is valid for service 1

request_4_create_api.json > Create API that represents service 2

request_5_reload_apis.json > Force a reload of the definitions in the gateway

request_6_second_key_request > does a PUT to the key created in step 3 to update the permission so it has access rights to service1 and service2

The dashboard and gateway logs are also attached in case they’re helpful

Any ideas?


Imported Google Group message.
Sender:Martin Buhr.
Date:Tuesday, 11 August 2015 15:38:15 UTC+1.

Hi Richard,

Yes it is odd, but it harks back to some early changes we made to how Authentication and Authorisation are handled in Tyk, it’s not actually a work-around, it’s the way it’s supposed to be. deep breath:

Tyk separates out Authentication from Authorization, and has two different interfaces for this: AuthenticationHandler and SessionHandler, the first will confirm if a key is valid, while the other will only check if a key exists, a subtle difference I know, but nonetheless important. When Tyk sees a key in an inbound request, it queries the session handler for the key, if it doesn;t exist, it queries the authentication handler, if the auth handler returns the key, the session data is transferred to the session store for ongoing use until the key expires.

It is important to note that the Authentication handler and Session handler can have different storage back ends, in a default Tyk setup, theya are the same one (Redis), but they don’t have to be. This actually means that for any API, keys can be retrived from one back end, and all session maangmeent can be handled on a completely different one on a plug-and-play basis (you can configure it in the API Definition).

When Tyk creates a session (creates a key), it does so with the Session Handler, and since a key can exist across multiple APIs, and those APIs can have multiple Auth+Back-end / Session+Back-end combos, when we perform any operations on token, we need to know which back-end to use. When we have the sesison data, we know this from the actual access rights in the key, and if it’s a master key, then we actually write the key to all available session back ends (which is why we discourage their use).

However when retrieving a key, we need to know which back-end to use, and it isn;'t specified in the key itself, and so we require an API ID.

The whole API for the key management sits under the API resource, mainly to keep the interface sane, except for the key creation:

Get("/apis/:apiId/keys/search/", (*APIContext).SearchKeys).
Get("/apis/:apiId/keys/:keyId", (*APIContext).GetKeyDetail).
Put("/apis/:apiId/keys/:keyId", (*APIContext).UpdateKey).
Delete("/apis/:apiId/keys/:keyId", (*APIContext).DeleteKey).
Get("/apis/:apiId/keys/", (*APIContext).GetKeys).

Key creation:

Put("/keys/:keyId", (*APIContext).UpdateKey).
Post("/keys/", (*APIContext).CreateKey).

The problem is we left in the old PUT(!), and the documentation wasn’t updated to reflect the other changes, which is why it seems so incherent, but underlying it all is the requirement to be able to query different back-ends on a per-api basis.

Just a note on the separation of Auth/Session, if you have a separate authentication handler, you would never create a key in tyk, you would create them in your Authentication store (which Tyk does not control, only queries, e.g. Active Directory or your own User Store).

There’s an LDAP back-end bundled with the tyk gateway source as a PoC for this if you want to take a look actually, it’s a nifty feature - basically you could write your own authentication logic, AND hook up your own back end, the same goes for the session handler, or jsut drop in new back-ends for each with the default handlers, it’s quite flexible. The idea was for integrators to be able to customise Tyk to their own environments if needed without too much source-code surgery.

Hope that clarfies things a bit :slight_smile:


Imported Google Group message.
Date:Tuesday, 11 August 2015 14:34:10 UTC+1.


I think I know what it is, your step 6 request URI is wrong, your step 6 request URI should be:


This will update the key appropriately for both APIs.

It’s an inconcistency in the API structure, we’re aware of it, and it’s something we’re looking to fix in future versions, I just looked at the docs and they are wrong, so it’s no surprise really :-/

Let me know if that helps.


Imported Google Group message.
Sender:Richard Hulm.
Date:Tuesday, 11 August 2015 15:07:39 UTC+1.

That did indeed fix it.

Thanks very much. Bit odd that I have to include an API ID to update a key? Would be nice if as you say it would be fixed in future versions so can update the key as I was trying to, I’ll use this workaround for now.


  • show quoted text -

Imported Google Group message.
Sender:Richard Hulm.
Date:Tuesday, 11 August 2015 17:27:14 UTC+1.

Ahh that makes a lot of sense!

We hadn’t looked at API-specific key management yet, so far the provided session&authentication handlers are getting us there. Will look into what you’ve suggested, but got it all working as we want it now so thanks for your detailed replies!


  • show quoted text -