Skip to main content ↑ ↓
Topic: HybridAuth in favour of our own OpenID implementation. (Read 7321 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

HybridAuth in favour of our own OpenID implementation.

Just a thought, but what do you think about using an open Library for third party authentication in favour of our own which currently supports only stateful OpenID 2.0.
This one looks very cool:
http://hybridauth.sourceforge.net/
HybridAuth is dual licenced (MIT / GPL3) and supports all common platforms (OpenID 1.1 / 2.0, oAuth etc)

They have a large list of build-in Auth providers (Facebook, Google, Twitter, Windows Live, Yahoo, LinkedIn, Foursquare..) and plugins for not so common ones such as steam, github, lastFM and many others..

Elk 1.0 or a later release?
Core or addon?
 
Thorsten "TE" Eurich
------------------------

Re: HybridAuth in favour of our own OpenID implementation.

Reply #1 –

I like the idea of a library for that ... its one of those specialized areas, that yes we can do but then there is the ongoing maintenance care and feeding ... seems like our time is better spent elsewhere.

Personally I'd like that in 1.0 ... the ability to use your google login etc is very nice, plus some of the capabilities of that lib will work nice in the profile area (something for 1.1 is a revamp of that).  Just having it in place gives addon writers something cool to play with as well.

Looks "easy" to plug in, not sure how much work is involved to integrate it.

Re: HybridAuth in favour of our own OpenID implementation.

Reply #2 –

 emanuele thinks is a good thing!

I already proposed an external library a long time ago to handle OpenID, if there is one that can do all of them at once, even better! :D

We can have it in ext, and it may even be possible to update it as a mod without having to upgrade Elk in order to have the latest version in case of changes or new authentications! :D

ETA: an open issue https://github.com/elkarte/Elkarte/issues/216
Last Edit: September 23, 2013, 05:52:18 pm by emanuele
Bugs creator.
Features destroyer.
Template killer.

Re: HybridAuth in favour of our own OpenID implementation.

Reply #3 –

hrr..  started working with HybridAuth and found the first bug in their OpenID class >:( Took me some hours to debug ..

It may take a while to integrate it in Elk but at least I'm making progress  ;D
Thorsten "TE" Eurich
------------------------

Re: HybridAuth in favour of our own OpenID implementation.

Reply #4 –

Looking forward to how it integrates ... bummer there are bugs right up front, with all the activity on that I'm kind of surprised.

Re: HybridAuth in favour of our own OpenID implementation.

Reply #5 –

I suppose that if we are going to integrate it, it may be the opportunity to "rework" the login code too in order to make it easier to extend, am I wrong? O:-)
Bugs creator.
Features destroyer.
Template killer.

Re: HybridAuth in favour of our own OpenID implementation.

Reply #6 –

Quote from: emanuele – I suppose that if we are going to integrate it, it may be the opportunity to "rework" the login code too in order to make it easier to extend
yep, I've tried to integrate it for a couple of days now and I'm tempted to give up...  HybridAuth doesn't seem t like Elk's session management. They want a session_start(); directly before calling their interface or at least the name of the exisiting session..

Wanna give it a try? :P
Thorsten "TE" Eurich
------------------------

Re: HybridAuth in favour of our own OpenID implementation.

Reply #8 –

mhh, yes.. opauth might be a better alternative.. Briefly checked it last week or so.. It seems to be beyond my skills :D  Wasn't able to get it working, even as a standalone version I failed completely ..
Thorsten "TE" Eurich
------------------------

Re: HybridAuth in favour of our own OpenID implementation.

Reply #9 –

Let's say that playing with it few minutes I did:
1) extend the class to rewrite the parseUri method in order to handle Elk's url schema instead of "friendly urls",
2) played a bit with github and google,
3) failed firstly because of localhost settings, then fail because of a redirect loop...
It seems kind of working, but there is some trick I'm missing... lol
Bugs creator.
Features destroyer.
Template killer.

Re: HybridAuth in favour of our own OpenID implementation.

Reply #10 –

oh, wow. Far more than I managed to do  :)
Thorsten "TE" Eurich
------------------------

Re: HybridAuth in favour of our own OpenID implementation.

Reply #11 –

...well, the "kind of " means that it redirects back, not that it works! :P

ETA: and there could be a "plan b": we take up development of HybridAuth too.
Bugs creator.
Features destroyer.
Template killer.