This is awesome Dragos +1 I think everybody by now realize that with web actions and having access to the request and response, there is a lot of modules in ExpressJS that cab be leverage in OpenWhisk without re-inventing the wheel (web server) :-)
Don't know if you saw last post from Lionel [1] uses a webaction to wrap an existing express app, my proxying the request and response. I think he publish some initial work on npm [2] and github [3] I think he is planning on part 2 of the article to include authentication You work is very interesting to the point of creating an action that can be shared as standard middleware in OpenWhisk apps, in terms of composition, I think it feats very well in a sequence composition were this action will be the gatekeeper to handle the auth and get the user token which outputs to the next action which doesn't have to be a webaction it can be a traditional action. The output of the traditional action, would then be pass to an action that knows how to build the http response (i.e. statusCode, headers, body), as you can see there can be action in the center of the sequence that never new they were in the middle of a request/response flow. Rodric coined the term "webify" an traditional action, where thissequence action can be created with an Action, as you can see we like to eat our dog food a lot META !! I think there is a need for both a library and a package that offers this helper functions, that people don't have to re-invent just to make web actions handle expressjs middleware. In terms of delivering this package in openwhisk-catalog repo, I think I want to go in opposite direction right now it's a big monolithic repo that I want to break out into individual repositories. So I proposed having a repository named something like "openwhisk-express", we can put the npm libraries/modules and re-usable actions in this repository and deploy them to openwhisk by default as part of postdeploy step that today we only deploy catalog packages, but we should also deploy the other packages in OpenWhisk like alarms, kafka, etc.. Having in it's repo also makes it easy to deploy it with wskdeploy in case you have your own copy or different version of the package One minor comment on your README that I didn't follow, we currently don't have passport installed in nodejs6action runtime, to use your repo as is today I need to create a zip first, can't use the .js as your doc show right? [1] https://medium.com/openwhisk/deploying-express-js-apps-to-openwhisk-part-1-9133ba5f262c [2] https://www.npmjs.com/package/openwhisk-expressjs [3] https://github.com/lionelvillard/openwhisk-expressjs --Carlos On Mon, May 8, 2017 at 11:30 AM James Thomas <jthomas...@gmail.com> wrote: > This looks amazing! Great work - will have to try it out. > > On 7 May 2017 at 23:03, Dascalita Dragos <ddrag...@gmail.com> wrote: > > > Recently I’ve been trying to see if we can reuse PassportJS with > OpenWhisk > > in order to create a User Authentication experience in a Serverless > > fashion. PassportJS is a Node library that supports 300+ authentication > > providers and this is what made it appealing. > > > > The use-case I was after was to enable developers to authenticate users > > with multiple providers. > > > > As an example: when users backup, upload, or edit a photo in a Cloud > > Storage service, register a webhook as an action that automatically syncs > > the photo with another Cloud Storage service. For such a scenario the > > action needs 2 tokens, one for each service, in order to access user's > data > > in both places. > > > > My first step was to see if we can run PassportJS in an OpenWhisk action, > > without having to depend on an Express server. This action would be > > responsible with user authentication, without being concerned with > storing > > any user tokens; the assumption is that other actions could handle this > > concern of caching tokens in a secure way, and making them available to > the > > actions that need them. So the “authentication” action would only reuse > > PassportJS, login users, and output the tokens. > > > > Eventually I was able to adapt PassportJS to an OpenWhisk action. You can > > find the code here: > > https://github.com/ddragosd/experimental-openwhisk-passport-auth > > > > The good news is that with less than a couple of hundreds LOC OpenWhisk & > > PassportJS can authenticate users in a lot of systems. So far I’ve tried > > authentication with GitHub, Twitter, Facebook, and Google, and it works > > flawlessly. The code of the action is ~240kb, including the libs > supporting > > these providers. > > > > The tricky part was to decouple Passport from Express / Connect, by > > providing simple implementations for request/response objects, as they > > should work differently in a serverless environment; this resulted in a > > fine-grained level of control for the response of the action, which > proved > > to be useful. > > > > The way the action works is that developers can create multiple OpenWhisk > > web actions reusing the same code, an action for each provider; for each > > action they get to set default parameters like client_id, client_secret, > > scope, corresponding to each provider. Each provider has its own unique > > URL. > > > > It would be nice if we can make it straight forward in OpenWhisk for > > developers to create actions that listen to events from a variety of 3rd > > party providers on behalf of the users, and then be able to do something > > useful on user’s behalf; user authentication plays an important role in > > this. To some extent I’ve also been thinking what it would be like for > > developers if this feature would come with the OW catalog. > > > > > > Looking forward to hearing your feedback, > > > > Dragos > > > > > > -- > Regards, > James Thomas >
