An Apigee Edge API Product lets you restrict access to proxy resources based on some combination of proxies and resource paths. When you add a Product to a Developer App, you can use the keys generated for that App to enforce this restricted access.
When you create a Product, Edge lets you specify zero or more proxies and zero or more resource paths to define the "restrictions" you wish to achieve.
But wait, what does it mean if you do not specify any proxies? Or, if you don't specify any resource paths? Or, for that matter, if you omit both? This is a frequent source of confusion for Edge developers!
API Products 101
Here's a common Product setup. Let's say you have a proxy called StreetCarts, which lets you find information about local food carts. The basepath of this proxy is /streetcarts.
Now, let's say you want to allow access only to certain resources that the proxy knows about. You can do this by adding both the proxy and the resources you wish to allow to an API Product. For example, here's what the Product UI would look like, where the resource paths /reviews, /carts, and /menus are listed and the proxy StreetCarts is specified:
 |
Using an API key from a Developer App associated with this Product, the following call will succeed (assuming ABCD is a valid key and the VerifyApiKey proxy is used in the proxy). It succeeds because the basepath of the StreetCarts proxy is /streetcarts and both the proxy and the resource path /carts are in the Product:
GET /streetcarts/carts?apikey=ABCD
But this will fail, because the resource path /users is not in the Product:
GET /streetcarts/users?apikey=ABCD
This also fails, because the basepath of the proxy StreetCarts is not /foodcarts:
GET /foodcarts/carts?apikey=ABCD
The following path fails as well since the basepath by itself is not allowed in the above configuration. If, however, you do want to allow the basepath, one option would be to add "/" to the list of resources in the product, which (by default) allows the basepath and all subpaths to go through.
GET /streetcarts?apikey=ABCD
To learn more about how to allow or exclude resources based on wildcards, see Configuring the behavior of a Resource Path of '/', '/*', and '/**'.
Be careful when omitting proxies and/or resource paths
Now, what happens if you omit proxies and/or resources from the Product? You need to be aware of potential risks with these kinds of setups!
When you specify resource paths but omit proxies
If you include paths in the Product, but do not specify any proxies, then keys associated with the Product will work for ANY proxy; however, requests will only succeed for the given paths. Consider the following configuration:
 |
Given this setup, this hypothetical call will succeed:
GET /basepath_A/accounts?apikey=ABCD
And so will this!
GET /basepath_B/accounts?apikey=ABCD
The basepaths don't matter, because no proxies are specified in the Product. So, any proxy basepath will be a potential match for the given key. However, proxy requests will only succeed if a valid resource path is given. For example, this call will fail because /carts is not specified in the Product.
GET /streetcarts/carts?apikey=ABCD
When you specify proxies but omit resource paths
If you specify one or more proxies, but no resource paths, then your API key will work with ALL RESOURCE PATHS in the specified proxy(s), including just the basepath.
 |
The following API call will succeed:
GET /streetcarts/carts?apikey=ABCD
The following call will also succeed because all paths, including the basepath, for the StreetCarts proxy are allowed:
GET /streetcarts?apikey=ABDC
However, this will fail, because the basepath for the specified proxy (StreetCarts) is /streetcarts, not /foodcarts:
GET /foodcarts/carts?apikey=ABCD
No proxies, no resources: Beware the skeleton key option!
A skeleton key is a key that opens any lock in your house. If you create a product with NO proxies and NO paths, then the key associated with that product can be used with ANY key-protected proxy in your org. In the UI, such a configuration would look like this:
 |
This option may be useful for testing, or for very specific use cases. But be sure you understand the effect of creating a Product with no proxies or paths. Skeleton key!
You can read more about creating products in the Edge documentation.
@dino
@Ricardo
@support
What is the effect of the "revisions" choice when using the "import resource" type of proxy/resourcePath entry?
Also, will selecting the latest revision allow the authority to automatically update when a new revision of an imported resource is created?
Revisions are just used to provide the resource path dropdown list when you use the "Import Resource" functionality. They are not saved as part of the product. @wwitman - maybe add a section about the Import Resource box?
Thanks, @Mike Dunker -- I'll update the doc to make sure this is clear.
Who do i specify the resource for below scenario?
Proxy 1 (StreetCarts)- Access to all resource path (/**)
Proxy 2 (foodcarts)- Access to specific resource path (/carts)
Hi @Maivizhi A -- sorry for the very late response. That is a quirk of products -- unfortunately the proxy and resource paths are two separate lists. Even though you think you can specify them together using the UI, there is no connection between the two. That means that specifying /** would give that wildcard (full) access to any of the specified proxies.
Contributors
59 People are following this .
