Does the ID Extractor Support Multiple Headers as Key?

Support Setting up Tyk
,
1

Hi Tyk Team,

As far as I know, ID extractor is used to cache the authentication / authorization process. And I can set a header value as key in the id_extractor config (in API config json file).

Currently we’re using Authorization header value as the key (which is set in api config file).

"id_extractor": {
  "extract_from": "header",
  "extract_with": "value",
  "extractor_config": {
    "header_name": "Authorization"
  }
}

But now we want to add a new header — say Origin. Both these two headers need to to be verified in custom authentication plugin. In this case, if we only set Authorization as key, the cache might have problem dealing with Origin header

Is there a way to do it (to use two keys or use a combination key)? Thanks!

1 Like
2

I am thinking you could another API definition as a proxy. The API definition would be marked as internal and would handle the second header before finally forwarding the request upstream. This is just theory but I guess it should work. If I find any other approach I will reply on this thread.

2 Likes
3

Hi @Olu ! I’m revisiting this issue recently and have a few questions :grin:

As for the question I previously asked, we simply disabled the cache and let the auth middleware do the auth every time, since we don’t have much traffic and our client is not sensitive to latency

We’re setting up a new service recently, and it requires us to do the Authorization header as well as a cookie validation at the same time, so the same question comes again. I’m trying to solve this problem once and for all this time

There’re several options i can think of, and I’m wondering if you could help evaluate them:

  • set up another api definition as a proxy. I haven’t tried it out, but as you said, in theory it works. My concern is just it might complicate our api definitions
  • disable id extractor and set up a cache in the auth middleware side, which can be managed by us. it adds up the traffic time between gateway instances and middleware instances, but it can be neglected since in-node network time should be < 1 ms
  • use a pre middleware, reference — Cookie + Authorization Bearer. It looks like it works. One question is that pre hook should be run before id extractor, if my understanding is correct

Looking forward to your insights! Thank you!

1 Like
4

I found that the 3rd solution might be the best, and we have an existing example shared on the github :slight_smile: !

1 Like
5

update on this

since we’re using a rich plugin for auth already, i added the preHook logic in the rich plugin as well (i didn’t know that and thought i need to use a jsvm native plugin). Anyway, that solved our issue!

1 Like
6

Great to hear you solved this :+1: