Feathers: JWT Token expireIn > 24d causes a overflow error with Sockets

[TheSinding]

Information about the bug

When you set the JWT Token expireIn to greater than 24d (~24,855) it causes a overflow error when you authenticate with sockets, REST is not affected by this.

This means that a connection in the app.channel('authenticated'); gets removed, which in turn means the events from feathers does not get published to clients.
But it still works as a valid authentication token.

I figured the timeout timer is to remove a connection from app.channel('authenticated') when the token expires.
I found the part which removes it in the authentication library. Link

Snippet from the file jwt.ts

      // The time (in ms) until the token expires
      const duration = (exp * 1000) - new Date().getTime();
      // This may have to be a `logout` event but right now we don't want
      // the whole context object lingering around until the timer is gone
      const timer = setTimeout(() => this.app.emit('disconnect', connection), duration);

The problem is that setTimeout() does not fit more that 32bit, see here, and in the documentation for NodeJS it says

When delay is larger than 2147483647 or less than 1, the delay will be set to 1. Non-integer delays are truncated to an integer.

Steps to reproduce

Create a new project, set the expireIn to >24d, then authenticate using a socket.

Expected behavior

When a socket authenticates it should still be in the connection pool of app.channel('authenticated');

Actual behavior

It authenticates then it is removed from the app.channel('authenticated'); immediately.

System configuration

Tell us about the applicable parts of your setup.

Module versions (especially the part that's not working):

{
    "@feathersjs/authentication": "^4.3.0",
}

NodeJS version: v12.9.1

[KidkArolis]

Tricky.. if we want to support such long tokens, the implementation might have be to be rewritten to use some sort of sorted map (insert each connection into a sorted map, every second or so check what needs to be removed). I could try working on that, unless there's a simpler fix.

Another option is something like https://www.npmjs.com/package/set-long-timeout.

Another, perhaps the simplest option is to setTimeout(.., Math.min(duration, 2147483647) or even a shorter number which would basically destroy the connection and the client simply has to reconnect. Because it's unlikely that someone would be connected for ~24d and if that's the case, they would definitely have to have reconnect logic built in (like feathers client has).

[daffl]

Well, now I finally understand why this package exists 😄 The simple fix for now would probably indeed be to use https://www.npmjs.com/package/long-timeout.

[daffl]

Fixed in v4.3.1

[TheSinding]

Noice, great job! :tada: