I try to delegate to Tyk the refresh (and extend) of expiring time for our auth tokens associated to tyk keys, every time a call it’s made to the API.
I see the webhook for expired keys but I think it’s too late to make a refresh.
Any suggestion ?
A custom middleware can provide this functionality ?
Thanks in advance for replys !
To myself, this it’s explained in the docs referring the plug-ins and middleware specifications.
To good to be true !
Hi Xavier,
Did you figure this out then or do you still need help?
M.
Thanks, Martin.
I think I can go with your documentation and examples.
If not, don’t worry … I let you know 
Can I update session.expiry time from a middleware script ?
Docs explain that in middleware only meta_data keys can be added/updated…
I see the event handler sample tied to KeyExpired event, but I don’t know if it’s the correct way to do it…
You can use the TykSetKeyData built-in method to set session data, the IP Rate limiter blog post uses it.
Don’t seems to work…
[Apr 22 13:16:40] INFO jsvm-logmsg: Running refreshExpiry POST PROCESSOR JSVM middleware type=log-msg
[Apr 22 13:16:40] INFO jsvm-logmsg: 56d5c67ef1f70e026c0000018e8b01a97ca34cc4753d84b0e4a115ed type=log-msg
[Apr 22 13:16:40] INFO jsvm-logmsg: 1461323947 type=log-msg
[Apr 22 13:16:40] INFO api: Key added or updated. expires=1461324400 key=56d5c67ef1f70e026c0000018e8b01a97ca34cc4753d84b0e4a115ed
[Apr 22 13:16:44] INFO jsvm-logmsg: Running refreshExpiry POST PROCESSOR JSVM middleware type=log-msg
[Apr 22 13:16:44] INFO jsvm-logmsg: 56d5c67ef1f70e026c0000018e8b01a97ca34cc4753d84b0e4a115ed type=log-msg
[Apr 22 13:16:44] INFO jsvm-logmsg: 1461323947 type=log-msg
[Apr 22 13:16:44] INFO api: Key added or updated. expires=1461324404 key=56d5c67ef1f70e026c0000018e8b01a97ca34cc4753d84b0e4a115ed
[Apr 22 13:16:49] INFO jsvm-logmsg: Running refreshExpiry POST PROCESSOR JSVM middleware type=log-msg
[Apr 22 13:16:49] INFO jsvm-logmsg: 56d5c67ef1f70e026c0000018e8b01a97ca34cc4753d84b0e4a115ed type=log-msg
[Apr 22 13:16:49] INFO jsvm-logmsg: 1461323947 type=log-msg
[Apr 22 13:16:49] INFO api: Key added or updated. expires=1461324409 key=56d5c67ef1f70e026c0000018e8b01a97ca34cc4753d84b0e4a115ed
This is my script …
var refreshExpiry = new TykJS.TykMiddleware.NewMiddleware({});
refreshExpiry.NewProcessRequest(function(request, session) {
log("Running refreshExpiry POST PROCESSOR JSVM middleware")
log(request.Headers["Authkey"])
log(session.expires)
if ((session.expires > 0) && (typeof request.Headers["Authkey"] != 'undefined')){
session.expires = ((Date.now() / 1000) | 0) + 600;
TykSetKeyData(request.Headers["Authkey"], JSON.stringify(session), 1);
}
return refreshExpiry.ReturnData(request);
});
log("refreshExpiry POST middleware initialised");
Do you see anything wrong ?
Hmmm, it might be the local session cache, because you can see it is applying an addition in the expiry when the key update is reported.
In your tyk.conf try disabling it:
"local_session_cache": {
"disable_cached_session_state": true
},
It’s already disabled…
And the API has
“cache_options”: {
“cache_timeout”: 60,
“enable_cache”: false,
“cache_all_safe_requests”: false,
“enable_upstream_cache_control”: false
},
Hmmm, you’re trying to dynamically extend the keys validity am it shows up am I right?
Have you tried checking the key manually using the API?
Yes the same first value shows up
This is a request cache. As in, caching actual responses.
Let me have an experiment and see what’s going on.
Ok, it is indeed a bug - basically what happens with post-processing middleware is that it expects a SessionMeta object back, and it writes that SessionMeta object to the session currently held in the request context, which it then updates to the key store. So if you run a keystore update within the request handler, it updates and then gets immediately overwritten with old data because of the meta-data write.
I’ve pushed a fix to develop branch (this will be reflected in the nightlies by tomorrow) that fixes this behaviour in post processing middleware.
In the mean time you can achieve the same thing with a pre-processor that pre-sets the key if it valid:
var refreshExpiry = new TykJS.TykMiddleware.NewMiddleware({});
refreshExpiry.NewProcessRequest(function(request, empty) {
log("Running refreshExpiry_with_session PRE PROCESSOR JSVM middleware")
var key = request.Headers["Authorization"]
var session = {}
var found = false
if (key != "") {
log(key)
rawSession = TykGetKeyData(key, "e1d21f942ec746ed416ab97fe1bf07e8")
session = JSON.parse(rawSession);
log(session.expires)
found = true
}
if (found == true){
log("Setting key data")
session.expires = ((Date.now() / 1000) | 0) + 600;
log(session.expires)
TykSetKeyData(key, JSON.stringify(session), 1);
}
return refreshExpiry.ReturnData(request, {});
});
log("refreshExpiry_with_session PRE middleware initialised");
A quirk with the get key is that you need to specify the API ID.
Thanks Martin for your support and workaround, I try it ASAP.
As a suggestion, If we can mess with the session data anyway (with the TYkSetKeyData), why don’t let to update it inside middleware scripts ?
It would be easier for all of us…
We though about it - but initially we wanted to restrict the capability of the scripts, now that we have the JS API it is a bit easier. Also remember that some middleware scripts might never actually get a session, so we wanted to manage that more explicitly.
I compile the develop branch with your patch and it’s working fine, thanks Martin
Any thoughts on adding key refresh as a feature rather than having to use middleware?
Since deserializing the session data in the JSVM is expensive, it’d be nice to have this done in Tyk perhaps when checking auth or ratelimits or some other operation which should have access to the session