How to ensure a user's email is verified before they can sign in - needs feathers-authentication changes

[ekryski]

Related to feathersjs-ecosystem/authentication#391.

---

Original bug report by @IBwWG

OK, so, as a newcomer, I really am not sure where exactly this issue fits into this repo, but @eddyystop is pretty involved here so I'm taking his word for it. :) (Original issue is at https://github.com/eddyystop/feathers-starter-react-redux-login-roles but I'm assured that it's not about that repo.)

Steps to reproduce

1. git clone https://github.com/eddyystop/feathers-starter-react-redux-login-roles/
2. npm install
3. npm start
4. curl -X POST -H "Content-Type: application/x-www-form-urlencoded" -H "Cache-Control: no-cache" -H "Postman-Token: 95cf199c-f038-c893-7053-a8a09fbef2ca" -d 'name=i have a name&username=nammmmmmmmmmme&password=what the hey&confirmPassword=what the hey&email=[email protected]' "http://localhost:3030/users"
5. curl -X POST -H "Content-Type: application/x-www-form-urlencoded" -H "Accept: application/json" -H "Cache-Control: no-cache" -H "Postman-Token: 018a022f-bf1b-7e4f-cf11-db40a5fce490" -d 'email=[email protected]&password=what the hey' "http://localhost:3030/auth/local"

Expected behavior

Failure, since I never verified with the "e-mailed" token. (i.e. I didn't use the link that appears in the console at step 4.)

Actual behavior

Success and JWT token given via JSON. If you scrap the Accept header in step 5, you get a similar result served up in HTML.

System configuration

This is happening both on a Windows box and a Linux box am I testing on.

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

feathers-authentication 0.7
feathers 2.0.3

NodeJS version:

Windows: node 7.3.0
Linux: node 6.9.2

Operating System:

Windows: 7x64sp1
Linux: Mint 17.3 (32-bit)

Module Loader:

see https://github.com/eddyystop/feathers-starter-react-redux-login-roles

---

I think the main issue is around documentation or we should have a hook that someone can use to ensure that an email exists and has been verified. Currently the way I see this working is a hook after auth.hooks.authenticate or it is a custom verifier for feathers-authentication-local that upon looking up the user by email also ensures that the email has been verified.

[eddyystop]

feathers-authentication-management's isverified hook checks if the email address has been verified.

feathers-authentication is not aware of the fields maintained by feathers-authentication-management. When that happens, the isVerified code can be moved into feathers-authentication-local.

[musicformellons]

Could you maybe comment:

1. Is this scheduled any time soon?
2. I need this, is this doable? And what is suggested way to implement this using current feathers-authentication and feathers-authentication-management and feathers-authentication-local.

[eddyystop]

@marshallswain ^^^

The hooks to do this yourself are documanted https://auk.docs.feathersjs.com/api/authentication/local-management.html#hooks

Code: https://github.com/feathers-plus/feathers-authentication-management/blob/master/src/hooks.js#L42

[musicformellons]

Thanks for the reference to the docs. I am not sure what is best practice:

1. have users make an account (with limited features) and then get them to verify their emailaddress
2. make an account only after they verified their email

Currently my setup is 1 and it works, but 2 makes sense as the original issue already mentioned 'bots could easily make lots of accounts etc.'. When choosing 2 I would not know how to do it as the isVerified is a property of user, so you first need to create a user to have isVerified set to true, right?!

[musicformellons]

I found this article and for now I will move forward using process 1.

[eddyystop]

Interesting. Most people tend to go with option 2.

[HarisHashim]

@eddyystop giving this package a try today and also having same problem (i.e. in my case I can get login token without email is verified).

I can understand when you write above that

The hooks to do this yourself are documanted https://auk.docs.feathersjs.com/api/authentication/local-management.html#hooks

But where should I use that hook to disallow auth token creation or login for those with email not verified?

Thanks!

[eddyystop]

Are you using the isVerified hook? That will prevent a successful login regardless of what you get back. This repo works in conjuction with the Feathers authentication routines, it does not, and it cannot, override them.

[HarisHashim]

I have not use isVerified hook yet because no idea where to put them.

But I found a workaround by customizing authentication-local verifier as per this documentation

Since I am using Feathers CLI. My modification is in \src\authentication.js

  class CustomVerifier extends Verifier {
    // The verify function has the exact same inputs and 
    // return values as a vanilla passport strategy
    verify(req, username, password, done) {
        // My custom code as per documentation
    }
  }

  app.configure(local({
    Verifier: CustomVerifier
  }));

A bit of a hack. It works, but please let me know if I should do something else.

[eddyystop]

@HarisHashim You should be using the isVerified and addverification hooks as described in https://github.com/feathers-plus/feathers-authentication-management/blob/master/src/hooks.js rather than hacking authentication-local.

[HarisHashim]

Can I get sample code on how to do this?

Something like adding hook for autentication-local in the same source code file?

[eddyystop]

@HarisHashim I believe the article explains what to do.

[danlupascu]

I don't know if you still need help with this issue but the solution is very simple: add the isVerified hook in the before hook of authentication service.

Example: (You only need to add two lines to this service)

// Your imports
// !!! Import the verification hooks
const verifyHooks = require('feathers-authentication-management').hooks;


// src/authentication.js
module.exports = function (app) {
  const config = app.get('authentication');

  // Set up authentication with the secret
  app.configure(authentication(config));
  app.configure(jwt());
  app.configure(local());

  app.configure(oauth2(Object.assign({
    name: 'google',
    Strategy: GoogleStrategy
  }, config.google)));

  app.configure(oauth2(Object.assign({
    name: 'facebook',
    Strategy: FacebookStrategy
  }, config.facebook)));

  // The `authentication` service is used to create a JWT.
  // The before `create` hook registers strategies that can be used
  // to create a new valid JWT (e.g. local or oauth2)
  app.service('authentication').hooks({
    before: {
      create: [
        authentication.hooks.authenticate(config.strategies),
        verifyHooks.isVerified() // !!! Add the isVerified hook before authentication
      ],
      remove: [
        authentication.hooks.authenticate('jwt')
      ]
    },
    after: {
      create: [
        context => {
          // Add the user to the result response
          context.result.user = context.params.user;
          // Don't expose sensitive information.
          delete context.result.user.password;
        }
      ]
    }
  });
};

[eddyystop]

I believe the all issues here have been addressed. If you have any new comments please make them in authenticate-local-management rewrite.

Full details on the rewrite are posted to https://github.com/feathers-plus/authentication-local-management/blob/master/misc/upgrading.md