How can I use the JavaScript policy to examine custom attributes from multiple API Products

[kalyaninturi]

I am trying to get all custom attributes under a API-product using JavaScript policy.

Scenario - My App might have multiple products and each product will have its own custom attributes.

I tried

 context.getVariable('verifyapikey-{policy_name}.app.apiproducts) ;

which gives me Ljava.lang.String087@10. But when I iterate through that object I got list of product

names. Then I loop through list with product names and tried to get custom attribute value using below

code, but i got empty value.

context.getVariable('verifyapikey.{policy_name}.{product_name}.{custom_attribute}' )

Is there any other way or other policy in apigee to accomplish this.

[dchiesa1 · Accepted solution]

I think the pattern is

verifyapikey.{policy_name}.apiproduct.{custom_attribute_name}

In other words the variable name is not dependent upon the name of the API Product that contributes the attribute.

All the custom attributes are lumped into one bucket. Can you try that?

BUT, having said that...I'd like to detour into a related issue.

Why do you have a set of products for a single API Key. It's certainly valid and legal. But in my experience most people who do that are using the API Product concept incorrectly.

An API Product should wrap up all the API Proxies needed for a particular use case. In most cases there will be one API Product associated to an API Key.

[kalyaninturi]

Related issue :

i developed a oauth proxy where request must send scope as form param to generate access token.I verify requested scope against the product scope in app ( set of all products scope in that app).

if request scope is subset of product scope set in app, then I will allow client to generate access token otherwise request should fail.

you are saying each api product should have single API-key, I understand you are talking about access token not the client key, am I correct?

[dchiesa1]

No, I'm not saying each API product should have a single key. I'm saying, "think outside-in". I'm suggesting that people should think "how will a developer consume my services" and the easiest way to do that is with a single API Product that aggregates the necessary APIs for the developer's purpose.

Then, provision credentials for an app. That app probably needs access to a single, curated API product.

I haven't said anything about tokens. We're discussiing provisioning of client credentials, and how API Products should be designed.

[#5]

Below are two options I can suggest

1. use multiple api key verification policies and use the flow variables to get the variables

2. you can do a management service call to get the information inside javascript policy (not mostly suggested, still can be done).