Imported Google Group message.
Sender:[email protected]
.
Date:Thursday, 28 May 2015 10:36:31 UTC+1.
Hi Rhys,
Answers below:
Thanks for the information. Unhashed mode seems to be exactly what I was looking for. We’re not currently using the portal provided by the dashboard as we have our own web app that we’re planning on hooking into Tyk.
Note that the portal is the thing which handles all the developer records etc. Tyk Gateway does not have any conept of a developer, the portl/dashboard adds this abstraction as an integration feature, it basically does everything via the tyk REST API and stores data, that’s it.
In terms of generating these keys, from investigating a bit further the workflow internally seems to be to create a key associated to a specific organization, which is then stored in redis as apikey-{api key}, with the full details in the body of that entry. This key is then added to the developer’s api_keys map, with the key being the API ID, and the value being the API Key.
Correct, except that there is no api_keys map if you are not using the developer portal. Also, the record that is mapped in the portal for API ID is arbitrary, as a key can grant access to multiple upstream APIs, we’re thinking of re-jigging this data structure to make it more sensible. Again, don;t rely on the developer record unless youa re using the portal.
Based on this information, I should be able to automate generating developer API keys by first sending off a key request, then updating the developer object with the resulting key ID. Are there any downsides to this approach? I haven’t found any evidence that keys generated by an admin user are associated to that user, so in theory this approach should work.
Assuming that the developer object in question here is your own, stored in your cusotm portal, then yes, this is what the Tyk portal does, essentially:
- Grab a key template (basics of a key, some base settings need to be present such a an initial access rights rule etc.)
- Set the apply_policy field to the key policy to be used to manage this class of key - this is super handy and we reocmmend doing this so that you can control access rules, quotas, rate limits etc across groups of keys
- Send the create key request to Tyk with this session object
- Tyk replies with the KeyID,
- Store this in your local developer record - instead of storing against the API ID, we suggest storing against the Policy ID, this way you can buklk manage these keys and their access rules, as well as managing the policies themselves with the Tyk REST API, makes integration / tiering easier.
In tyk, tokens are treated as ephemeral, as they may be revoked or destroyed at any time, keeping your DB version in sync with the Tyk gateway can cause lookup errors, just be aware of that. There are settings to handle session lifetimes and key expiry times both in the key temlate and globally, see the docs for the details on this.
Hope that helps.
Cheers,
Martin