Support passport.js

[thegoleffect]

Functional support, tests, & coverage by 2/4.

[thegoleffect]

I'll be in the office on Monday & need to factor in documentation; pushing back the ETA just a tad.

Functional support, tests, & coverage by 2/6.

[thegoleffect]

Status update:

Passport<->Hapi functions mapped and functional (though authenticate() is not yet as fully featured as the express one). Thus, I can login with Facebook OAuth2 and any other Passport-X strategy easily, but at the moment... without sessions support (so the mapped functions request.logout, request.isAuthenticated, etc... don't do anything useful). To take advantage of sessions, I need to create a usable 'passport' hapi authentication strategy which sets/gets request.session.

No updated ETA until I dig in some more. API mockup forthcoming, I need to determine the best way to define auth config but everything else is already similar, if not identical, to passport's standard express API.

Most of the code is in Passport and within hapi configuration, there has been very minimal tweaking required in hapi itself - which has been nice.

[hueniverse]

Take a look at the new Cookie auth strategy I just added and see if that will work for session support.

[rmanalan]

@thegoleffect can you share your code (in a feature branch possibly)? I'm trying to get passport working on my app... I can wait for the session support, but for now, I just want to hook up the pieces and get basic login working. Thx.

[smclaughry]

+1 on the feature branch, or temporarily partial functionality. I'm anxious to see this working in my app as well.

[thegoleffect]

Feature branch with Iron-cookie support (client-side, persistent session storage) should be pushed today (EOD 2/11/13).

Feature complete, merge-able branch with database-backed session support should be complete by 2/13.

---

Most practical use cases of persistent or smart sessions will work optimally with the Iron cookie method. Anyone storing 100 KB or more in their user session data would be better served by the DB backed method.

[rmanalan]

awesome! thx!

[dhigginbotham]

sounds awesome @thegoleffect, thanks for all your hard work thus far.

my life is hapi'er.

hapi hapi joi joi

[thegoleffect]

A cut down version of the code can be found at https://github.com/thegoleffect/hapi-passport

The code is meant for debugging/clarity purposes, is not yet entirely functional, and is missing all the goodies like retry. Also, we have plans to greatly simplify the API via the hapi-passport module so most of the boilerplate shown in the example will move behind the scenes.

There are currently two major outstanding issues:

• hapi-jar API needs a way to clear parts of the cookie (may be undocumented, investigating that now)
• extension order matters, so wrapping the session saving code to onPostHandler when using hapi-jar causes session saving to occur AFTER the jar has already been saved (this needs a better workaround than a manual callback in the handler) \ Considering a push/shift parameter to the .ext function

[recipher]

Hi. What is the current state of this? I see there has been some activity in the last couple of days in https://github.com/thegoleffect/hapi-passport, however, if I npm install this and try to use it, then it fails because Boom and Hoek are not dependencies. Also, if I manually add those dependencies myself, then I get a runtime error:

   this.server.plugin().register(Yar, options, this.onPluginErr);
                                  ^
   ReferenceError: Yar is not defined
      at Diplomat.configure (/Users/recipher/Code/starcount/catalog2/node_modules/hapi-passport/lib/index.js:49:35)

Which I haven't been able to figure out.

I see mention of adding this into a feature branch of hapi. Any ETA on this?

Thanks, Johnny

[hueniverse]

We're in the process of finalizing our plugin api which is a dependency. This is all part of 0.14. I'm hoping passport support will be usable next week.

[recipher]

Marvellous, thanks. I'd also be interested in understanding what you might be considered "best practice" when it comes to hooking this up.

To explain:

We will have a hapi API which will be used to access social media data, from the usual suspects - twitter, facebook, etc.

We also have another API which is used to access our application data, including "user" information.

We also have a couple of client applications (web only at the moment) which will authenticate the user, using FB or Twitter or whatever.

To gain access to the APIs, the user will (perhaps) need to be authenticated (with FB etc). In addition, the social media API would need access to the user's access tokens so that they can retrieve information from the networks (timelines, status updates, etc).

I'm undecided on the best way to handle this sort of scenario. Use Basic Authentication when accessing the APIs? Pass access tokens in headers? The APIs will have no notion of "session", that is for the client applications. Users will authenticate within the client applications, and then the client application (either a server-side application, e.g. Express or similar, or a client-side application, e.g. Backbone) will be responsible for passing along Application authentication (through Basic Auth headers) and access tokens (through additional headers, which ones? not sure yet, need to find out).

Does that sound right to you? Sorry if this is somewhat off topic. Passport seems eminently suitable for website authentication, but for API authentication, when using FB etc, I'm not so sure that that is the best plan.

Perhaps I should ask Jared.

Thanks for your time. So far, we love Hapi.

[recipher]

You can ignore my ramblings above. I think I more or less answered my own question. Thinking more clearly about our usage, I don't think we need to use hapi-passport, we will just use basic auth (or hawk, perhaps) to authenticate the APIs, and the client apps will use passport and passport-facebook etc.

[hueniverse]

It depends on the API authentication model you are using. If you need simple client-server auth, use Basic over HTTPS or Hawk (with or without HTTPS). If you need delegation, you need something like OAuth or Oz (which is not yet ready). The trick with using FB to log into a client that then uses an API is that if the API server is not involved in the FB auth, it is easy to spoof. This is a complex topic... :)

[thegoleffect]

Sorry for the delay and lack of communication. Been working hard to make the production use as painless as possible.

All of the passport-hapi code has been consolidated and factored out into proper locations. APIs are pretty close to final. There were numerous changes and bugs as part of the move towards Hapi 0.14.x. I am coordinating with Jared towards having him publishing (hopefully) the Passportjs version that supports Hapi on Wednesday (1361971800000 aka Feb 27, 2013).

Hapi-passport (name change imminent) and yar with sessions will be published (all working with semi-final APIs) on Tuesday (1361885400000 aka 2/26/2013).

[thegoleffect]

@recipher If I am understanding your use case correctly, my best practice suggestion is for the passport.js to hapi auth should be used strictly for web (calls made over a browser). Immediately after a successful auth, when loading/saving user data, you could generate/regenerate your own access token for a particular user to use for API calls (and just verify those tokens) or use any of the Hapi built-in auth schemes.

But if the API calls are being made from the browser (like ajax requests, Backbone.js, etc ... and thus have access to the cookies), no additional access token is required (passport sets a session cookie).

Hope that helps.

[thegoleffect]

Hapi-passport is now called "Travelogue". It has been updated to match Jared's PR#104 linked above.

Session API awaiting final approval and imminent publish in walmartlabs/yar. I've tested it rigorously on my local box and it works very well so far.

There is one outstanding Travelogue bug left. If the server is restarted while using memory-backed session storage, the cookies and session IDs are useless and the server may behave erratically. So the server needs to be aware and react accordingly. This fix is required to use Passport with any practical authentication strategy (like Facebook/Twitter/etc). That bug should be wiped out late today (2/27/2013) or early tomorrow (2/28/2013) and ready to be published live with full documentation shortly thereafter.

I am SOOOO ready to use this in my own Hapi apps. Sorry for the delays everybody! It is almost done!

[recipher]

Excellent. Thanks for your hard work.

[dalmaer]

So using user/pass with a mongo backing is 100% aok right?

On Wed, Feb 27, 2013 at 4:16 PM, Van Nguyen notifications@github.com wrote:

Hapi-passport is now called "Travelogue". It has been updated to match Jared's PR#104 linked above.
Session API awaiting final approval and imminent publish in walmartlabs/yar. I've tested it rigorously on my local box and it works very well so far. There is one outstanding Travelogue bug left. If the server is restarted while using memory-backed session storage, the cookies and session IDs are useless and the server may behave erratically. So the server needs to be aware and react accordingly. This fix is required to use Passport with any practical authentication strategy (like Facebook/Twitter/etc). That bug should be wiped out late today (2/27/2013) or early tomorrow (2/28/2013) and ready to be published live with full documentation shortly thereafter.

I am SOOOO ready to use this in my own Hapi apps. Sorry for the delays everybody! It is almost done!

Reply to this email directly or view it on GitHub: https://github.com/walmartlabs/hapi/issues/437#issuecomment-14209007

[alimoffr]

Thank you!

[thegoleffect]

In case you haven't checked it out, Travelogue was published last week (https://github.com/walmartlabs/travelogue).

@dalmaer Yep, as you know, local-storage support is working. The tiny tiny normalization code in the example will be baked into 0.0.2.

[pabl-o-ce]

what happen to this plugin? @hueniverse can you recommend a good plugin for OAuth 2.0

[gergoerdosi]

@pablocarreraest: The repository is here: https://github.com/hapijs/travelogue. The README says:

This module is no longer being maintained. There will be no future releases. Please migrate to either hapi-auth-cookie or bell.

[pabl-o-ce]

thanks for the info @gergoerdosi what should plugin you will recommend me for made a oauth

[cjihrig]

@pablocarreraest check out https://github.com/hapijs/bell.

[pabl-o-ce]

@cjihrig bell is for consume and I want to create a OAuth for a API project or I'm just not know what bell is for...

[cjihrig]

You might want to check out @geek's https://github.com/geek/OAuth.

[StarpTech]

@pablocarreraest do you know grant? https://github.com/simov/grant

[pabl-o-ce]

@cjihrig or @StarpTech I found https://github.com/dwyl/hapi-auth-jwt2 with some good examples.

thanks guys!