User object missing in logout callback args under certain conditions

[daffl]

From @kkkrist on April 17, 2018 21:18

I have a weird problem using app.on('logout', callback) on the server.

In my macOS-based dev environment it works just fine. The callback receives fully populated result and meta objects as arguments, of which I'm using meta.connection.user to update some data in the db.

In my Linux-based production environment however, meta.connection contains just this:

{
  "provider": "socketio",
  "payload": null,
  "user": null,
  "headers": {}
}

Both environments use node v9.11.1 with npm packages installed from an identical package.json. The only real difference in setup is a reverse proxy on the production server, but bypassing it doesn't change anything.

From package.json:

"dependencies": {
  "@feathersjs/authentication": "^2.1.5",
  "@feathersjs/authentication-client": "^1.0.2",
  "@feathersjs/authentication-jwt": "^2.0.0",
  "@feathersjs/authentication-local": "^1.1.2",
  "@feathersjs/configuration": "^1.0.2",
  "@feathersjs/errors": "^3.2.2",
  "@feathersjs/express": "^1.2.2",
  "@feathersjs/feathers": "^3.1.4",
  "@feathersjs/socketio": "^3.2.1",
  "feathers-authentication-hooks": "^0.1.7",
  "feathers-blob": "^2.0.0",
  "feathers-hooks-common": "^4.11.0",
  "feathers-nedb": "^3.0.0",
  "nedb": "^1.8.0",
  "socket.io-client": "^2.1.0"
}

What's going on here? Where should I look at next? Any pointers would be much appreciated!

– Christian

P.S.: When looking for a quick workaround, I've discovered a Symbol key in meta.connection which is also present in the production environment and contains all data needed. So my workaround now looks like this:

if (
  !connection.user &&
  Object.getOwnPropertySymbols(connection).length > 0
) {
  connection =
    connection[Object.getOwnPropertySymbols(connection)[0]]._feathers
}

Copied from original issue: feathersjs-ecosystem/socketio#116

[daffl]

This indeed seems like a strange issue since nothing in that process should be doing anything OS specific. I'll see if I can reproduce it in my local Linux test environment.

[daffl]

From @kkkrist on May 3, 2018 13:6

Thanks for looking into it, it's very much appreciated! I have created a test case here:

https://github.com/kkkrist/feathersjs-logout-callback-test

Curiously enough it does always receive an almost empty meta.connection object, no matter if i run it in my dev or prod environment:

{ provider: 'socketio', payload: null, user: null, headers: {} }

I'm almost sure I did miss something… but what? Thanks again!

[daffl]

From @bertho-zero on May 3, 2018 14:56

This is probably due to feathersjs-ecosystem/authentication#665.

[daffl]

Oooh, this actually might be an issue because logout will also be sent when the socket disconnects and reconnects and I don't think reconnecting sets that information again.

[daffl]

From @kkkrist on May 3, 2018 19:2

Confirmed, that's it.

The unstripped params can also be found in meta.socket._feathers, which I'm using now to get the user id. That's much better than my quirky initial workaround.

Is meta.socket._feathers supposed to be internal? If not, should the docs be updated? I guess being able to determine the user in a logout event might be something a lot of real-time apps need. And the fact that a disconnected socket (i.e. closed browser window/tab) triggers it is really neat.

P.S.: It's obvious now, but this was never an OS specific issue. It turned out I've .gitignored package-lock.json some time in the past, so @feathersjs/authentication most probably wasn't the same version in both dev and production.

[daffl]

From @ricardopolo on July 17, 2018 22:29

I confirm this issue.

I am always using connection[Object.getOwnPropertySymbols(connection)[0]]._feathers instead the connection object that arrives in the logout event.
Sometimes it comes empty

[3kynox]

Hello, I'm facing the same. Any news about this bug?

EDIT: I found the user object in a weird location, so I'm using it:

app.on('logout', (authResult, { socket: { _feathers: connection }}) => {
    if (connection) {
        (...)

[daffl]

This has been addressed in Feathers v4 authentication. See the Migration guide for more information on how to upgrade.