LinkedIn
Twitter
1 ACCEPTED SOLUTION
Every app that gets created will add 2 entries in the KVM. On key regeneration, I want these values to be transferred over to the new client id as well.
Ahhh, yes... You should use custom attributes on the app.
In Edge, the hierarchical model for entities is:
-
developer
-
app
- credential (== client_id + secret)
-
app
And you can attach attributes to any level of that hierarchy. From within the Edge UI, you can read and update the custom attributes on the developer, or on the app. From within the Edge UI, you cannot see or manage the attributes on a credential. For any of the 3 entity types, you can read and update custom attributes via the Apigee Edge administrative API. But I think you don't want to store credential-specific (aka client_id specific) data. You want the data to be attached to an App. And that's easy to do from within the Edge Administrative UI. Here's what it looks like:
(Oops! you said OPDK, so I guess you will be seeing a different style of page for Developer App Details. But you will see the same information if you are on the current patch level.)
And, every time an API request arrives bearing the API key, or a token derived from that API key, and your API proxy invokes VerifyApiKey or VerifyAccessToken, respectively, the message context will have access to these custom attributes, implicitly . So you could do whatever you like with that data.
Regarding regeneration, here is a side note: In current versions of Edge you do not "regenerate" the client_id, you can simply add a new client_id, and maybe if you like remove the old one. And those client_id's will be unique and will have independent and possibly overlapping lifetimes. But there is no "regenerate". In fact the old "regenerate" did nothing but delete the old client_id and add a new one. Today (latest OPDK), those operations are explicitly separated in the UI.
Regardless of the number of credentials configured for the app, the custom attributes will be available in the message context directly after the API proxy validates any valid non-expired, non-revoked token or client_id.
You are limited to, I think, 20 attributes. I apologize for the uncertainty, check the doc to be sure. The reason I don't know: I never use 20, or more than about 4 or 5. If I have a whole bunch of stuff to store, I put it into a JSON string, and store that string as the value of the custom attribute. Then it can be flexible and I can write a simple JavaScript callout to parse the JSON out of the custom attribute and do what I want with it.
As another example, I have stored PEM-encoded public keys into custom-attributes attached to apps. Then at runtime, the API proxy can de-serialize the public key and verify a signed payload, knowing that it was signed by the holder of the private key (the app).
And yes, you can read and update those attributes via administrative API calls. Or, you can attach attributes at the time you create the app. This looks like the following:
POST :mgmtserver/v1/o/:orgname/developers/developer@example.com/apps
Content-type: application/json
Authorization: :edge-auth
{
"attributes" : [ {
"name" : "key-1",
"value" : "attrvalue-put-anything-you-like-here"
}, {
"name" : "key-2",
"value" : "another-value-here"
}, {
"name" : "key-3",
"value" : "{ \"prop1\" : \"value1\" }"
}
],
"apiProducts": [ "ValidProductNameHere" ],
"keyExpiresIn" : "86400000",
"name" : "AmitTestApp"
}
The value for each attribute MUST be a string; you cannot put a JSON hash there directly. If you want a JSON value, stringify the object, and then store the resulting string. (it means all the quotes will be escaped). BTW, unrelated to custom attributes, the keyExpiresIn value is in milliseconds. Omit it, if you want a never-expiring key.
To directly answer your question, though: KVM is not appropriate for storing app-specific data. Instead, use custom attributes attached to the app.
