Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auth "after" hooks and events not fired on reconnect if the first connection was unsuccessful #1714

Closed
panstromek opened this issue Nov 29, 2019 · 4 comments

Comments

@panstromek
Copy link

Steps to reproduce

Using this code on client with realtime and auth on the server.

 feathers.service('authentication').hooks({
    after: {
      all: [ctx => console.log('auth')]
    }
  })
feathers.on('login', () => console.log('auth'))
feathers.on('authenticated', () => console.log('auth'))

feathers.reAuthenticate().then(/* ... */)
  1. Turn the server off.
  2. Reload the app.
  3. Get the timeout error (correct)
  4. Turn the server on
  5. Look at the dev tools - feathers reconnects, create authentication is sent, response received, but nothing shows up in the console - eg. no registered hooks or events are fired

Note:
This error happens only on the first connection, if the first attempts were unsuccessful.

Hooks and events are correctly fired if the app disconnects and reconnects again after it was already connected.

System configuration

Feathers: 4.4.1
NodeJS version: 12
Operating System: Win 10
Browser Version: Chrome 76

@daffl
Copy link
Member

daffl commented Nov 30, 2019

Related to #1532 - clearing the buffer would fix it. But the timeout should really be removed.

@panstromek
Copy link
Author

Note: Quick workaround for this for now is to call force reAuth on reconnect event like this ;)

socket.on('reconnect', () => {
  if (!app.authentication.authenticated) {
    app.reAuthenticate(true)
  }
})

@daffl
Copy link
Member

daffl commented Dec 2, 2019

This should happen automatically already. #1696 was supposed to fix the reconnection behaviour with queued requests as well. I'll have to double check what's happening there.

@daffl
Copy link
Member

daffl commented Jan 17, 2020

I believe this should work now in the latest version. The next major version will probably remove the client internal timeouts and let the connection (REST/Socket.io) handle that.

@daffl daffl closed this as completed Jan 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants