Keystone-classic: Social media login plugin for Keystone

[estilles]

I've developed a social media login plugin that I currently use on my Keystone projects. My intention has been to publish it as an npm module called keystone-social-login (unless anyone has any better suggestions).

Currently it works by passing your instance of Keystone to the plugin, which then literally plugs itself into Keystone. Among other things, it redirects the Keystone signin url to a page that includes links to all the configured social media logins, as well as to Keystone's login page.

While this "plug-in itself" mechanism has been working well for me so far, I would much rather see a more standard method for instantiating plugins. I was wondering, now that we're creating a more plugable ecosystem for Keystone when it comes to fields and storage providers, if we intend to move ahead with a standard plugin architecture, similar to what was described in #185.

Creating a standard plugin architecture/API of this nature, IMHO, would allow Keystone to support a host of features that should not necessarily be part of its core functionality. A user-supported ecosystem of plugins would be of incredible benefit to Keystone's growth. It would definitely bring us to par with other more "plugin-friendly" CMSes, such as WordPress. I'm personally not a WordPress fan and would choose Keystone over it every day of the week and twice on Sunday, but we can't deny that it has an impressive plugin ecosystem.

I echo @dboskovic's ideas in #185 and like the simplicity and elegance of @danielmahon's suggested implementation, though I would personally advocate a slightly more robust API.

I guess my question to everyone is: Should I/we put off plugins of this nature until Keystone officially supports a standard plugin architecture (I would be more than happy pitch in and collaborate on this) or should we simply publish our plugins "as is" for the time being? Personally, I think a standard plugin architecture is right in line with the direction of 0.3.x.

Comments, suggestions and constructive criticism is always welcome!

[webteckie]

I am in total support. The plugin's API should allow the plug-in to operate at the different stages of the keystone startup process. I would assume that just installing the plugin via npm is not enough but that it can also be activated/deactivated independent of the install.

I would be very happy if you publish your social plugin as-is as I was contemplating creating something similar. And, yes, with the understanding that the way it plugs in may drastically change in the future:-)

[estilles]

@webteckie, thank you for your comments.

Yes your are correct in assuming that installing the plugin via npm would be suffice. The plugin API would provide some means to register the plugin, in the same fashion we register middleware with Express using app.use(middleware). Maybe something like:

var awesomePlugin = require('awesome-plugin');

// with default options
keystone.plugin.register(awesomePlugin);

or

// with user-defined options
keystone.plugin.register(awesomePlugin, { opt1: 'x', opt2: 'y' } );

or something along those lines. I haven't really worked out all the details of the API.

As for your request, I will start working on converting my plugin into an npm module. I will post an updated as soon as I test/publish.

Initially the plugin will support the following strategies:

• passport-facebook
• passport-twitter
• passport-google-oauth
• passport-github

These are the only ones my customers have requested so far. I plan to add more strategies in future releases. However, in the mean time, if there's a specific strategy you need just let me know and I'll do my best to include it in this first release.

[JedWatson]

@JohnnyEstilles I'd actually vote for this to be built directly into Keystone core (at least to some degree). It's a very common request and really useful functionality, and would (I think) benefit from tight integration - including the availability of it in the standard sign-in screen.

The social sign in on the SydJS site was developed as a prototype (primarily by @bladey) with the intention of being able to pull it back into Keystone, is your work based in any way on that or separate? When this is published we should update that project as a usage example, and add it into the Yeoman Generator as well.

I also always figured that field types could play into this as well; I think it would be cool to have a Facebook field / Twitter field / GitHub field, etc. that could be dropped into the User model and provide at least _some_ of the functionality of interacting with those services, in the same way that Location fields abstract google geocoding.

It (social plugin, social field types) could certainly be separate npm packages but let's assume we can do whatever we like to make this work in Keystone's core too :)

re: Plugin architecture, this crosses over to custom field types, and is next on the list of "big things" to get finalised after the move to React, blocker being that the React architecture will change a lot about how these hooks are implemented.

Nothing blocking work starting on this immediately though!

[estilles]

Wow! Interesting. I wasn't aware of your interest in having something like this as part of Keytone's core.

I will still publish my current implementation on a public repo, so that individuals such as @webteckie, who have voiced an immediate interest in using it, can take advantage of what I already have done.

After that I will start working on integrating that functionality into Keystone's core. But first, I will post my ideas on what I believe would be the best course of action so that we can all discuss them here.

[webteckie]

@JohnnyEstilles, my needs are not immediate :-) If the way to go is to integrate it into the core then I can wait for that. I've got plenty of other things to address, which will keep me very busy for a while! Thanks!!!

[estilles]

@webteckie, thanks for the update. I probably will share it anyway (maybe not on npm, but at least on a GitHub repo), because there have been a number of folks that have been asking me to do so. I had just been really busy. I do appreciate the heads up though.

[JedWatson]

@JohnnyEstilles that's funny, I'm surprised I haven't said something about it before.

I'd love to see the repo you've created, but also kind of want to discourage plugins being released to npm until we've got an architecture we're ready to support.

Since it's sort of on topic, it's probably worth mentioning that there are (draft) plans to create a plugin ecosystem, with official plugins (which are tested and maintained as necessary with core Keystone development), as well as community plugins.

But the first step is getting to 0.3.x, and having a plugin architecture, so I'm focusing on that first.

[fbeaudet]

+1
@JohnnyEstilles I also would like to see what you've done, social media login is something I'll need to support by december.

[estilles]

@JedWatson, no worries. I understand that 0.3.x is now our priority. I'm eager to see your draft plans for the plugin architecture/ecosystem. I wonder how it compares with my own ideas on the subject.

@fbeaudet, will be publishing soon on GitHub (not npm). Right now I'm dealing with an issue related to the new Facebook scoped-ids. I hadn't realized the new implementation had negatively impacted several use cases of the plugin.

[estilles]

For anyone who is interested, I've published my social media login plugin on a GitHub.

Here's the repo:
https://github.com/JohnnyEstilles/keystone-social-login

If anyone is willing to test it and give me some feed back I would greatly appreciate it.

[estilles]

@JedWatson, I'll wait until we're a bit further along on 0.3.x to see how I can best integrate this into the new and improved Keystone core. I'd love to read your comments on the plugin. :-)

[estilles]

Just updated the documentation. I left out some important stuff last night (or I should say this morning). 1am is not the best time to write docs. :-)

[Globegitter]

@JohnnyEstilles That is a great plugin - just looking in using keystone for a project where we already have a login infrastructure in place and we are thinking of updating this to use add an OAuth login functionality, so we can us it with keystone. Since I just started looking into this, would it be easy to use/modify https://github.com/JohnnyEstilles/keystone-social-login to use a custom OAuth authentication system?

[kadosh1000]

Any news about integration with 0.3.x?

[VinayaSathyanarayana]

Any plans for social logins in the v4.x?
@JedWatson - Your inputs please

[HaswinVidanage]

Any news about integration with v3.x?
~ 2017