The ID extractor is there to prevent an additional round trip to the middleware - no more, so if you use it, your middleware won’t even be executed if the ID extractor finds the cached session object. Then when the cache expires, your code needs to supply a new one. It’a a speed boost, not state.
Perfect, thats what I want and that is my understanding. I’m just not seeing that work per my post @ NPM and JSVM, custom basic-auth plugin more details? - #19 by matiasb
If you want to persist state (the session object) across requests then you need to store it yourself and manage that yourself, it’s a custom auth handler after all.
Here is the confusion I guess. I want to do this, but you are saying the method above in fact does this, but yet here you say I need to do it myself? Confused.
In the example I was directed to for an JSVM “auth” plugin, the plugin returned a session object to the invoker of the function via returnAuthData. I was under the impression that doing this in combination with the “id_extractor” that a “session” would be established, keyed by the Authorization header and stored in redis. All subsequent invocations of the “auth” handler would be skipped until that session is expired.
I don’t have any need to track any meta-data particular to a user on the session. I just want to avoid repeated calls to my auth plugin which itself calls out to another service. One call per unique Authorization header, if it passes, estab this session keyed by the auth header, and don’t call my auth plugin again until that expires. Thats it.
Perhaps I need to do a call w/ you guys, as by reading the docs something is not clicking, some diagrams of the internal flow of tyk with regards to components that invoke w/ these plugins and the interaction w/ the thread might be helpful as the docs simply are not conveying this if I am mis-understanding it. We are evaluating this prior to purchase, had a call w/ James earlier in the week.