Strategy chaining about hapi-auth-bearer-token HOT 14 CLOSED

Happy to give you write access on this if you've any changes you'd like to make? http://openopensource.org/ FTW ;)

from hapi-auth-bearer-token.

This was fixed with #89. Great work @AdriVanHoudt, and good catch on checking for multiple strategies for route as well!

from hapi-auth-bearer-token.

@johnbrett was my pleasure! And this works out better than what I had on hapi-auth-bearer-simple 🔥 oss ftw

from hapi-auth-bearer-token.

This must be new, or I certainly haven't seen it before! "If the err does not include a message but does include a scheme name (e.g. Boom.unauthorized(null, 'Custom')), additional strategies will be attempted in order of preference."

By my understanding of this you're correct in the assumption here. Are you hoping to do chaining here? What's your use case, maybe I can help? :)

from hapi-auth-bearer-token.

Yes we are doing chaining, we have a separate strategy for private and public usage of certain routes of our api. We try private first then public.

I have quickly updated auth-simple (out of business needs) but I am in favor of just one to rule them all :D

from hapi-auth-bearer-token.

that would be cool, it would involve removing the error message and exposing the token in artifacts by default I guess

from hapi-auth-bearer-token.

can you not pass in the token in the application code to artifacts? e.g.

server.auth.strategy('simple', 'bearer-access-token', {
        validateFunc: function (token, callback) {

            // verify login token e.g. user = User.findById(token);

            if (user) {
                // now user and token are accessible from 
                // request.auth.credentials.user && request.auth.artifacts.token
                return callback(null, true, { user: user }, { token: token });
            }

            return callback(null, false, { token: token }, { artifact1: 'an artifact' });
        }
    });

meaning the library wouldn't have to be modified for the token. The library will need to be updated for the error message part though.

from hapi-auth-bearer-token.

I could but it would be easier if the plugin did it by default

from hapi-auth-bearer-token.

I wonder should it though. Is there ever a case we wouldn't want it populated by default I wonder?

from hapi-auth-bearer-token.

hmm not sure maybe @koresar knows since he has clearly used it before

from hapi-auth-bearer-token.

We do not use chaining. I would not recommend using that Hapi feature either. You would rely on some deeper Hapi mechanism - breaking change may happen there. Or you would need to change the chaining mechanism but second auth schema depends on the artefacts of the first auth schema (tight coupling). Etc.

We did a wrapper NPM module around this module where we could implement our chaining if needed. So, if we need to change auth schema across all our deployments we simply update our NPM module and redeploy our services. Voila!

However, @AdriVanHoudt your situation could be different.

That's how we do it:

      const credentials = {
        token,
        id: user.id,
        username: user.name,
        scope: false
      };
      const artefacts = {
        user
      };

      callback(null, true, credentials, artefacts);

I have no strong opinion weather hapi-auth-bearer-token should support chaining or not.

from hapi-auth-bearer-token.

This is a documented and handy feature, I don't see a problem relying on it.
You stated that the second scheme relies on the first one? How so?

Our server expect credentials to be the user object atm so changing that is not something I plan on doing ;)

The question I had was more about the effect of setting artifacts and if hapi does something special with it (with or without chaining)

from hapi-auth-bearer-token.

@AdriVanHoudt nice work, I left some feedback on the PR. I think it's a documented feature of the framework so happy for this plugin to support it.

I do think it's bad practice for a second auth scheme to depend on the first also, but I don't think that's what users will use chaining for.

from hapi-auth-bearer-token.

Yeah they should not depend on each other and if artifacts do this then that would not be a solution

from hapi-auth-bearer-token.