Locking down query string parameters to an API Key

Greetings,

Is there a way to lock down specific query string parameters to a customers api key?

i.e. source, format, count of articles etc.

Hmmmm, not really - tokens grant access and enforce rate limits/quotas, but they do not enforce ‘form’ (yet), do you have a use case you could describe? Might be an interesting new addition?

M.

Martin,

Sure here is an example in our current solution.

For api keys associated to endpoint “/articles/news/”

we have user 1 with this api key make the call with the following query string parameters:

api key=123456 (FullText=true&TextOnly=false&Count=20&format=rss&html=false&source=usatoday)

we then have user 2 with this api key make the call with a different set of qs parameters:

api key=654321 (format=nitf&count=10&sort=lastpublished%20desc)

By locking down a particular query string to a key, customers with different requirements can reference the same api call and pass in only the parameters they need without making the api call itself overly long and complex.

Ah, I see. I’m afraid we don’t have support for that yet, basically you’d like a kind of per-token request transform / mask that can be applied.

Nice idea, I’m pretty sure it’s something we can consider for a future release :slight_smile:

Martin,

We are currently using 3scale as an api solution. They did not have this functionality either, in order to get this working they added a some addtional logic to our current cookbook and we manage it with a lua file stored in the attributes. Is that something we could possibly move over to tyk since you do not have a solution for it at present?

You could look at doing custom JS Post-processing middleware and store the masks in the session meta_data of the session token.

Quickly thinking about it, your process would be as follows:

All tokens have a meta-data key/value map, so when you create a token, you can add some matched paths:

{
    "path/to/match": "key:value,key2:value2,key3:value3",
    "another/path/to/match": "key:value,key2:value2,key3:value3"
}

You then create a JS Middleware post processor that would look like this:

var pathManipulationMiddleware = new TykJS.TykMiddleware.NewMiddleware({});

pathManipulationMiddleware.NewProcessRequest(function(request, session) {
    // You can log to Tyk console output by calloing the built-in log() function:
    log("Running PATH POST PROCESSOR JSVM middleware")

    var pathFound = "";
    if (session.meta_data != undefined) {
        pathFound = session.meta_data[request.URL];
    }

    if pathFound != undefined {
        // we have a querystring mask, since it needs to be a string, split out on commas
        var parts = pathFound.split(",");
        for (var i in parts) {
            // Get the individual key/value pairs:
            var keyVal = parts[i].split(":");

            // Assign to request
            request.AddParams[keyval[0]] = keyVal[1];
        }
    }
    
    // You MUST return both the request and session metadata
    return pathManipulationMiddleware.ReturnData(request, session.meta_data);
});

// Ensure init with a post-declaration log message
log("PATH POST PROCESSOR initialised");

This will basically grab the injectors for the identity, and then add the key/value pairs to the outbound request as parameters. You could, if you wanted to even grab some from the inbound request and add those too (the above code is not tested, I jut threw that together as a demo).