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

Add ability to control if socket is marked as authenticated. #448

marshallswain opened this Issue Mar 18, 2017 · 2 comments


None yet
2 participants
Copy link

marshallswain commented Mar 18, 2017

I'm making a plugin that enables the workflow shown in the diagram, below. I'm overloading the authenticate method with strategies built on feathers-authentication-local with custom Verifiers, then using hooks for cleanup work.

app.authenticate({strategy: 'email', email, signature}) // returns a salt & challenge
app.authenticate({strategy: 'challenge', challenge, signature}) // returns an accessToken & secret
app.authenticate({strategy: 'two-factor', type}) // Requests that a 2FA code be sent.
app.authenticate({strategy: 'two-factor', signature}) // Authenticate with hash based on 2FA

What I need is the ability to conditionally mark the socket as authenticated. I think adding an {authenticated: false} to the params in a before hook would be good enough.

  before: {
    create: [
      auth.hooks.authenticate(['email', 'challenge', 'two-factor', 'jwt']),
      function (hook) {
        if ( === 'email') {
          hook.params.authenticated = false

Then we add a condition to the socket handler to check for this before marking the socket as authenticated, here:

This basically opens the door for multi-factor auth solutions to be built: #130

Some of the facts may not be quite straight in this diagram, but the basic idea is that the user can authenticate without having to ever send his/her password.

screen shot 2017-03-18 at 8 15 30 am


This comment has been minimized.

Copy link

ekryski commented Mar 22, 2017

Going to put what I sent to you in Slack here as well....

I follow what you've got here, but I'm wondering if re-using the auth-local strategy for all of those steps is really the right way to do this. It seems like it really should just be a custom passport strategy to handle all that hand shaking and then when all of it is done, it resolves so that the strategy calls back with a success.

I've done both multi-factor auth and "magic-link" auth in the same fashion you have (by overriding feathers-authentication-local). It works, but it's kind of hacky. In my mind they really should be passport strategies that you register.

My concern (a small one) with adding that bypass is that someone inadvertently sets that param and it causes weird side effects. I want to move away from having readable/writeable params on hook.params that we are using internally. They need to be more protected.

It also, kind of feels like a hack. @marshallswain we'll chat on a hangout because I might be missing something.


This comment has been minimized.

Copy link
Member Author

marshallswain commented Mar 30, 2017

These custom strategies actually mapped nicely into the local strategy. After one of the PRs last week, it's now possible to control socket auth by setting hook.params.authenticated = false.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.