elefant icon indicating copy to clipboard operation
elefant copied to clipboard

oAuth logins

Open jonphipps opened this issue 11 years ago • 3 comments

I need to have github, bitbucket, and perhaps dropbox login/linkage capability, in addition to Google, Facebook and Twitter. Should I be considering a 3rd-party composer class like https://github.com/opauth/opauth (which looks good, has lots of framework integrations, but feels unstable) or something that would be bundled like PHP OAuth API (which actually looks quite nice)? Or should I just copy the Facebook provider and cobble something together for each? Not sure what would fit best with your general dev philosophy.

jonphipps avatar Apr 26 '13 23:04 jonphipps

It would be good to move to using a 3rd party library like Opauth (HybridAuth is another to consider), instead of maintaining our own implementation for each provider, plus the support for all those extra providers for next to free. We'll still need a bit of glue code but probably less than what we've already got.

jbroadway avatar Apr 27 '13 15:04 jbroadway

The only problem I saw with HybridAuth was that it always returns a standardized user profile across all social logins. When I was building an exclusively GitHub-centric app a few months ago this was a bug more than a feature, since the github-populated profile was a bit sparse and I needed to go get the profile myself anyway. But that's probably a distinct advantage for Elefant. I've spent time with oauth and HybridAuth but right now php-oauth-api at phpclasses looks pretty compelling. The author has some very good reasons for not wanting to distribute via composer: http://www.phpclasses.org/discuss/package/7700/thread/64/ and it might be an easy-to-update included library.

If I implement one of these, do you have a preference? I wouldn't want to go in a direction that you're not comfortable with.

On Saturday, April 27, 2013, Johnny Broadway wrote:

It would be good to move to using a 3rd party library like Opauth ( HybridAuth http://hybridauth.sourceforge.net/ is another to consider), instead of maintaining our own implementation for each provider, plus the support for all those extra providers for next to free. We'll still need a bit of glue code but probably less than what we've already got.

— Reply to this email directly or view it on GitHubhttps://github.com/jbroadway/elefant/issues/185#issuecomment-17118006 .

Jon

jonphipps avatar Apr 27 '13 17:04 jonphipps

I'm open to whichever you think is best suited. Just looked and they're all license-compatible too :)

jbroadway avatar Apr 27 '13 19:04 jbroadway