Authentication about fastify

[jsumners]

I looked this last night. You will definitely need to work out #39 first if what you want is per-route authentication like Hapi supports. _routeHandler will need to have some sort of "authentication" API to query. I don't think the hook API will work for the situation; but I could be wrong about that.

[delvedor]

@jsumners behind the scenes we are working it on :)

[jsumners]

I think this goes with this issue. Let's say you have the following

fastify.addHook('preHandler', (fastifyRequest, res, next) => {
    let authError
    if (!fastifyRequest.req.headers['authorization']) {
      authError = Error('missing authorization header')
      fastifyRequest.log.error('unauthorized: %s', authError.message)
      // res.code(401).send({})
      return next(authError)
    }
    const authKeyParts = fastifyRequest.req.headers['authorization'].split(' ')
    if (authKeyParts.len !== 2 || authKeyParts[0] !== 'bearer') {
      authError = Error('invalid authorization header')
    }
    if (config.authorization.has(authKeyParts[1]) === false) {
      authError = Error('auth key invalid')
    }
    if (authError) {
      fastifyRequest.log.error('unauthorized: %s', authError.message)
      // res.code(401).send({})
      return next(authError)
    }
    next()
  })

The client will never get a 401 because the only way to not send multiple responses is to pass an error into next().

[delvedor]

Maybe I'm missing the point here, why you are not doing:

if (!fastifyRequest.req.headers['authorization']) {
  authError = Error('missing authorization header')
  fastifyRequest.log.error('unauthorized: %s', authError.message)
  res.code(401).send({})
  return // <=
}

?

[jsumners]

Because I was under the impression that you must invoke next().

[delvedor]

Well, it depends :)
next() is needed to continue the fastify lifecycle, but you can "interrupt" the lifecycle at any point by closing the request and adding a return if needed :)

Maybe we can be more clear about this in the documentation.

[jsumners]

I think that may be true. Anyway, the only reason I posted it to this thread is because, since I thought next() was required, I thought there would have to be some extra work done to support ending requests with error codes other than 500 (i.e. 401 - not authorized).

[jsumners]

So what is the vision for this feature @mcollina @delvedor ?

[mcollina]

I do not have time to write it at this moment, and I think @delvedor would need some guidance and help. Would you like to contribute (even if it's just flashing out an initial prototype, or giving @delvedor some reviews/directions).

[jsumners]

I'm willing to at least investigate if I am capable. But I need to know what the vision for the feature is. How is it supposed to work? Does it work differently than fastify-bearer-auth?

[mcollina]

the key concept are: strategies and schemas, similar to Hapi. However, the system should be fully encapsulated with plugins, while in Hapi schemas and strategies are global. I'm not sure if it's even possible :).

[jsumners]

That's what I suspected. I don't think it's even necessary if it even is possible. With the current encapsulation and plugin mechanisms it is very easy to register routes under authentication and non-authentication at the same time.

[mcollina]

Do you think this is fixed by #115? It might.

[delvedor]

I think it is, I'm working on a jwt based plugin that uses the beforeHandler function.
I'll show you something in the next days.

[delvedor]

I've added a proof of concept here.

[delvedor]

I think this can be closed, fastify-auth offers an utility to handle authorization and there are few examples, furthermore we are working on a Passport plugin.

Please reopen it if you think we should discuss more :)