FOSOAuthClientBundle
stof opened this issue · comments
This is a follow-up of #28 to continue the discussion about the client-side bundle for oauth.
IMO, the bundle should support both OAuth1 and OAuth2 as OAuth1 is still used (Twitter for instance)
Here are the current implementation available:
- http://knpbundles.com/mazen/EtcpasswdOAuthBundle by @mazen supporting OAuth2
- http://knpbundles.com/KnpLabs/KnpOAuthBundle by @geoffrey for @KnpLabs supporting OAuth2
- http://knpbundles.com/benji07/Benji07OAuthBundle by @benji07 supporting OAuth1 and OAuth2
From what I saw, the Knp bundle is the cleaner one from a design point of view, but it is still a WIP. So I think it should be the starting point for the consolidated bundle.
The first question is now: Do we move it to FOS (what do you think about it @geoffrey and @mbontemps ?) thus adding @geoffrey to FOS, or do we contribute to it under the Knp namespace ?
I personally do not care what namespace it's in, but I'd like to at least finish the basic implementation before moving it anywhere. I also think it would be best to extract the Security Component specific stuff before officializing the OAuth bundle (which, eventually, will only be a configuration wrapper around the Security Component, juste like the SecurityBundle if I understand correctly)
I still have a few things to figure out in the security component (like what the hell do I do with my OAuthToken), so I'm not sure when I'll be able to clean things up, but since @mbontemps will oppress me for using it in KnpBundles, I'm confident that it will be sooner rather than later :)
+1 for both OAuth 1 and 2
+1 to start with the Knp bundle. I discussed with @geoffrey and his implementation is probably the best.
Envoyé de mon iPhone
Le 18 déc. 2011 à 15:13, Christophe Coevoetreply@reply.github.com a écrit :
This is a follow-up of #28 to continue the discussion about the client-side bundle for oauth.
IMO, the bundle should support both OAuth1 and OAuth2 as OAuth1 is still used (Twitter for instance)Here are the current implementation available:
- http://knpbundles.com/mazen/EtcpasswdOAuthBundle by @mazen supporting OAuth2- http://knpbundles.com/KnpLabs/KnpOAuthBundle by @geoffrey for @KnpLabs supporting OAuth2
- http://knpbundles.com/benji07/Benji07OAuthBundle by @benji07 supporting OAuth1 and OAuth2
From what I saw, the Knp bundle is the cleaner one from a design point of view, but it is still a WIP. So I think it should be the starting point for the consolidated bundle.
The first question is now: Do we move it to FOS (what do you think about it @geoffrey and @mbontemps ?) thus adding @geoffrey to FOS, or do we contribute to it under the Knp namespace ?
Reply to this email directly or view it on GitHub:
#29
@geoffrey we talked about doing it with 2 repos: a standalone library handling OAuth (usable with Silex too for instance) and a bundle providing mainly the integration with SecurityBundle.
I'm fine about waiting until the basic implementation is done.
I was thinking it would be nice if the Security Component had OAuth in core actually. Do you think it would make sense to PR it with OAuth support?
I think it depends how complex it would be to implement it /cc @schmittjoh
But the big advantage about the approach I suggested previously is that it would be usable even when you don't use the Security component (which is overkill for Silex IMO)
@geoffrey, I think it better fits into a bundle. There is no real advantage of having it in the symfony repository.
Any update on this?
I really need an OAuth Client Bundle that support more than one provider but I don't know what to use.
If there was one within FOS it was probably stable enough and widely used, but currently there are too much of them!
It seems that most of the participants interested to improve the knp bundle, you may want to take a look at:
http://knpbundles.com/hwi/HWIOAuthBundle
Here is a quote of hwi (the author's organization):
The bundle was forked of KnpOAuthBundle with consent of the primary maintainer ubermuda in order to push the bundle forward faster as original creator currently didn't have the desired time for it.
It's also support multiple providers.
ok, thank you for informing the rest of us :)
Well, the first step is to finish the FOSOAuthServerBundle. Once done, we
will see, depending on the demand :)
Just a quick FYI. @asm89 has contributed a lot to KnpOAuthBundle before we resoluted that he would be better off forking it so he can actually work faster on it (my lack of time to dedicate to that bundle really slowed down his work).
Seeing as how HWIOAuthBundle is way ahead of KnpOAuthBundle, it wouldn't make much sense to merge it back to Knp namespace, so I think I'm going to deprecate KnpOAuthBundle in favor of HWIOAuthBundle and encourage people to use it and contribute to it.
Closing this as HWIOAuthBundle is a good implementation so there is absolutely no need to provide our own bundle