This article will give you an example on how you manage / restrict access to your API resources by verb and or the full basepath of the API.
Background:
To start this article off I would like to explain some of the common reasons for using this approach.
Common reasons to restrict by verb or base-path:
- Mixed Protocol Restrictions: I have a resource that i only want to give read-only access to, but have resources that still have write access in the product.
- Duplicate Path Suffix: I have two api resources that have the same path suffix but are in different proxies and i want to have different rules for access for each resource. e.g.
- /basepath1/v1/items
- /basepath2/v1/items
How It Works OOTB:
API Products currently look at a couple of things to validate if the request has access to a particular resource. Products then looks at the API Proxies that are associated and the API resource paths, these paths only compare the path suffix of the URI (everything after the base-path).
How to Extend OOTB Functionality:
There is a variable that if it exists it will be used instead of the proxy.pathsuffix to do the comparisons, that variable is flow.resource.name. So to extend the functionality we have to change the value of this variable before we validate our key or token.
Here is an example of some javascript to add both basepath and pathsuffix into the flow.resource.name variable
try{
context.setVariable('flow.resource.name','/'+
context.getVariable('request.verb')+
context.getVariable('proxy.basepath')+
context.getVariable('proxy.pathsuffix')
);
}catch(e){
throw 'Error in Javascript';
}
And in our product we then can add Resources that look like this:
Or if you want to use wildcards you can do something that looks like this
Note: That you have to use a URL like format to make this work seamlessly
Extra Note: You can use multiple * wildcards but you can’t mix * and ** wildcards