Add passport.findStrategy()

[paroga]

This allows us to have strategies depending on e.g. req.headers.host.

[paroga]

any comments on this?!?

[jaredhanson]

Could you post an example of how this feature would be used by a developer?

I understand the use case, and think its worth supporting, but I haven't had a chance to thoroughly review and think about alternative approaches.

[jaredhanson]

To clarify, I mean an example other than that in the source code. That example isn't doing anything that Passport offers simpler mechanisms for already.

[paroga]

If I have a server where the strategy is stored in the database (because the different users can configure their own specific login mechanisms) a possible implementation could look like the following (in a real implementation with caching and so on...):

passort.findStrategy(function(name, done) {
  // Start lookup in database...
  Strategy.findOne({name: name}, function(err, item) {
    if (err)
      return done(err);
    if (item.type === 'facebook')
      return done(null, new FacebookStrategy(item.config));
    if (item.type === 'google')
      return done(null, new GoogleStrategy(item.config));
    if (item.type === 'twitter')
      return done(null, new TwitterStrategy(item.config));
    return done(null, null);
  });
});

and something like

app.get('/auth/:strategy', function(req, res, next) {
  return passport.authenticate(req.params.strategy)(req, res, next);
});

The code changes should be minimal. Authenticator.prototype.findStrategyis copy&paste of Authenticator.prototype.transformAuthInfo, the change in lib/middleware/authenticate.js is only a change of a synchronous call to an asynchronous one (which leads to the 99% whitespace changes) and the rest are tests.

[jaredhanson]

Yep. I've got a similar use case. Quick question, do you primarily use this with OAuth providers (and other redirect-based IdPs). Do you use this with API authentication mechanisms like Bearer, Basic, etc?

[paroga]

Mainly with OAuth, since the usual use case is that a user will register his/her application at Facebook/Google/Twitter and configures the client ID and secret on my server. Providing different Basic implementation should be possible too (e.g. depending on the hostname for virtual host) but is not a real use case for me ATM.
I already thought about a more general OAuth implementation which would support an asynchronous callback for its configuration, but it seamed much more complicated and not so flexible to me.

[jaredhanson]

Right, I have a OAuth implementation that looks up configuration at run time, rather than passing into strategies. I'll try to clean that up and publish it, and let you know. Agreed that this approach is more flexible.

[paroga]

Since I have to get the user infos from the OAuth providers too and not all of them support OpenID Connect ATM the configuration lookup at run time would not solve all of my requirements. Making those callbacks somehow configureable or duplication the already existing code in the strategies does not sound like a good way to go for me.
Do you see any chance that my change (or a similar idea) can be merged into master?

[jaredhanson]

Yes. I'm catching up on the backlog now. Give me a week or two, and I'll get this (or something close to it) merged in. Sorry for the delay, but I prefer to move slow and consider security-related stuff from all angles. And thanks for the patch!

[paroga]

No stress. I agree on the security point. Just wanted to know if this idea will work out or if I have to find an alternative solution for my problem...
And a big THX for the cool framework! :-)

[paroga]

ping?

[martwetzels]

Is the findStrategy going to be merged into the master branch? Just looking for this exact solution for passport.

[markstos]

Was a different solution merged? I see references in the source code to "Strategy augmentation". Maybe that is related?

[ramod8]

Any update on this?