Should Geckos allow headers to be set in authorization?

[trezy]

So, I'm currently working on the piece of my game where the client needs to establish a connection to the server. The client has already authenticated with our auth system (Firebase) and is sending an auth token in the Authorization header for Geckos to validate. Once Geckos receives the connection, it attempts to validate the auth token.

At this point there are a few different error scenarios that can occur, but the one I'm focusing on is if the user's email is not verified. The user has an account, but they haven't clicked the verify link in their email. Until they click that link, they're not allowed to connect.

This is all hunky dory, except for the response to the client. My authorization function returns 401, which is great. It cannot, however, set a www-authenticate header as is required by §4.1 of RFC7235.

There's a relatively simple solution to this, which is just passing the response object to the authorization function. I wanted to bring this up in discussion before making a PR, however, because I'm not sure of the deeper implications of giving access to the response object. Is there a reason it's not available, @yandeu?

[yandeu]

I don't fully understand your question. But can't you just do something like this?

// client
const channel = geckos({ authorization: 'SECRET_CLIENT_TOKEN' })

// server
const io = geckos({
  authorization: async (auth, request) => {
    const clientToken = auth // SECRET_CLIENT_TOKEN

    const res = await requestToFirebase({ token: clientToken })

    if (res.status === 200 && res.email && res.emailIsVerified) return res

    return 401 // unauthorized
  }
})

io.onConnection(channel => {
  console.log(channel.userData) // will be whatever is in "res"
})

[trezy]

I can and that's pretty close to what I'm currently doing. The issue is that a 401 Unauthorized response can mean multiple things. For example, I send a 401 back when either the auth token is invalid, or when the email is unverified. There's currently no way of informing the client why the error occurred, though. This is what my authorization function currently looks like:

import { auth } from 'helpers/firebase'

export async function verifyAuthorization(authToken, request, response) {
	try {
		const result = await auth.verifyIdToken(authToken.replace(/^Bearer /, ''))

		if (!result.email_verified) {
			response.setHeader('www-authenticate', 'Bearer realm="game data channel", message="verification_required"')
			return 401
		}

		return result
	} catch (error) {
		switch (error.errorInfo.code) {
			case 'auth/argument-error':
				response.setHeader('www-authenticate', 'Bearer realm="game data channel", message="invalid_token"')
				return 401

			default:
				return 500
		}
	}
}

This doesn't work, of course, because response is undefined, but the point is that currently the only thing I can send back to the client is a status code. I'd like to be able to set a header, or at least send back a response body.

[yandeu]

I just added support for it (831a80a).

Check out the updated README file.

[trezy]

Woot, thank you so much! ❤️

Will that be released as 1.7.2, or is it going to come with 2.0.0?

[yandeu]

You're welcome :)

It will be in both. I have just pushed v1.7.2 to npm.