/ Sessions / Login / Signup

[des-des]

Update from Mavis

relates #100 I think the functionality of this is done now. This allows us to secure routes and allow users with correct tokens through routes. No routes have actually been secured as of yet

• Upon registering, a password is hashed into the db
• Upon login, a token is sent back in a cookie
• Routes can be secured by checking for a JWT in a cookie
• Routes can be permissioned by checking the scope of the user against a minRole allowed on the route
• There are tests for all the functionality (I think)
• also adds and tests new boomError handler

Questions

• When are we actually going to secure the API routes? That has not been done here.

• We could hash the password as a pre-save function on the User Schema, something like this:

  // Execute before each user.save() call
  UserSchema.pre('save', function(callback) {
  var user = this;
  
  // Break out if the password hasn't changed
  if (!user.isModified('password')) return callback();
  
  // Password changed so we need to hash it
  bcrypt.genSalt(5, function(err, salt) {
  if (err) return callback(err);
  
  bcrypt.hash(user.password, salt, null, function(err, hash) {
    if (err) return callback(err);
    user.password = hash;
    callback();
  });
  });
  });

  Not sure if we want to but would mean we couldn't ever add users without a hashed password

Old

• Sessions, we need sessions for users logged directly into OPT. Right now this pull implements JWT based sessions. Currently the auth expects the the JWT to be in a header, we should move this into a cookie so that it does not conflict with the oauth. This session / auth will be used for users who want to do 2 things.
  1. Create new apps
  2. authorise apps
• Permissions: Create middleware that can help us permission our endpoint.
  1. First we have authenticate the user, either from oauth token or from JWT in cookie.
  2. Second, on endpoints that require permissioning, we check the users credentials against those required for their action.

[mattlub]

@des-des please could you sum up what you're doing here (bullets maybe), and how it fits in with the other PR? Will be easier to pick up.

e.g. the other one needs a function which takes a request and returns a user (see here).

[des-des]

@mattlub The authorisation step (issueing a code) need the user to be authenticated. The login / session management in this pull will allow us to log a user into the platform and check the users credentials when the try to authorise an application.

I have also updated the top level comment

[m4v15]

So do we need to change this bit to put the stuff into a cookie? (at the moment, is this what allows you to use req.user in authUser.js)

[des-des]

@m4v15 yes, but also here https://github.com/foundersandcoders/open-tourism-platform/pull/95/files#diff-ba775ae7fd1ea884755adaf5125dc306R3

[m4v15]

I've changed it to use cookies and now test the routes, just need to add tests for the middleware

[m4v15]

@des-des @mattlub I think this is ready for an initial review, finishing off #100

[m4v15]

reminder for me of what to do after talking to eoin a bit:

• [x] use promises with super test
• [x] more thorough tests
• [x] make verify role a pure function
• [x] add an allowed through thing

[mattlub]

I haven't really looked properly at all of this- but does it include a function which takes a request and returns a user? This is what the oauth module needs

[m4v15]

@mattlub

So authSession.js looks at a request, looks for a token in a cookie, then verifies the token with our secret and attaches anything in the token onto req.user (at the moment we put username and user role in the token)

Is this what you mean?

[m4v15]

@des-des changed name to validate, and fixed the other things. I really hope this is done now...

[des-des]

Woop