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).
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!
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.
Hi @Olu ! I’m revisiting this issue recently and have a few questions
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
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!