Check chain of strategies on default server auth

[nakardo]

See: https://github.com/johnbrett/hapi-auth-bearer-token/pull/129

[lbvo]

@nakardo @johnbrett Super ! that was quick, I can't describe how grateful I am ! At first I could not get it to work, after updating the module.

I had replaced the unauthorized function, with a "custom" to simply strip some of the properties. I did that since I got many endpoints in my API where i validate the output, which made it more easy to make the response error validation by simply using the output of a boom method.

// ... some where in options :)
    accessTokenName, // renames the query token, access_token is default
    unauthorized: (message) => {
      // Default procedure would be to throw the unauthorized, however it can contain more attributes
      // making it harder to construct responses for swagger as the outcome may vary
      // so we are only interrested in the message to simplify this step for now
      throw unauthorized(message)
    }

When I removed the "custom" unauthorized function part it worked like a charm !

Actually just now, as I am typing this I tried changing the function of the "custom" unauthorized, to also contain the scheme attribute. so simply ... unauthorized: (message, scheme) => { throw unauthorized: (message, scheme) }

And that also works, which makes a lot of sense. Since I guess the scheme must be found in order to be checked for its settings? especially when it comes to allowChaining.

So its not really a big deal to be quite frankly, just something that could be added to the readme for some clarification. Just wanted to let you guys know. I can try to added to the readme if you like me to.

-- Thanks a bunch

[johnbrett]

That's interesting, thanks for the explanation @lbvo.

According to the docs: https://hapijs.com/api#authentication-scheme.

If the error includes a message, no additional strategies will be attempted. If the err does not include a message but does include the scheme name (e.g. Boom.unauthorized(null, 'Custom')), additional strategies will be attempted in the order of preference (defined in the route configuration)

You are indeed correct. A PR adding this to the README would be absolutely welcome, I'm sure it'll catch someone else!