Closed naktinis closed 11 years ago
I'd like to see this in the upstream too. It has been here for a month without any response, so I'd like to ask maintainers if there's any issue with that particular implementation. And if so, what can we help you to see this provider in the upstream as soon as possible?
@naktinis , I suppose it's necessary to make a pull request in either case.
Hello! Please don't hesitate to nudge me on these issues, I'm very busy outside of velruse but when there's interest I try to give it as much love as I can.
I'm glad to incorporate a google oauth provider. I was wondering if it was worth separating the api or simply integrating with the add_google_login()
api by just adding some more options and in a future release deprecating the openid+oauth1.0 options.
Well, I think the best solution is to have a separate "private" module encapsulated into velruse.providers.google
. Then we'd be able to do something like:
# velruse.providers.google
from . import _google_oauth2
def add_google_login(..., protocol='oauth1'):
# ...
provider = _google_oauth2.GoogleProvider() if protocol == 'oauth2' else GoogleConsumer()
# ...
In the future, if Google decides to remove OAuth1 protocol completely, we can merge this private module into velruse.providers.google
.
I think google.py
should be turned into a package where google/__init__.py
contains the includeme/setup functions and google/hybrid.py
contains the current provider and google/oauth2.py
contains your new provider. What do you think?
Also I agree that the protocol switch is a good idea.
Yes, I completely agree with you.
P.S. The module is provided by @naktinis
Just adding my support for this feature request.
I'd also like to add my support for this feature. I'd love to see this integrated soon.
If it's ok with everyone, I will refactor google provider into a package, add the protocol switch and start a pull request.
+1
I think this can be closed now, see 74d6148128c5eacfe54867ac01d2645893008ba7.
I was looking into cutting a release but this just isn't adding up API-wise. The context needs to be exposed as an API and it can't simply be GoogleAuthenticationComplete because that one already exists and subclasses OpenIDAuthenticationComplete, thus we have a naming clash.
I'm seriously considering removing the current google provider entirely because most of it can be covered by the current OpenID provider and the OAuth1.0 part of the protocol is now deprecated. At which point the "google" provider would just be the new OAuth2 implementation. I might be able to justify this because I am not familiar with any users of the hybrid system, but it does feel irresponsible. Right now I'm bouncing between doing this and/or naming it google_oauth2, but that's what's holding me up.
I think we should name it google_oauth2 and wait until Google officially closes down hybrid API. At that point we would have a fair reason to remove current default provider from the library.
So I've pushed this as google_oauth2 and renamed the original implementation to google_hybrid. I've left in a bw-compat shim in velruse.providers.google that makes it work the same as google_hybrid. Released 1.0.2.
Since Google OAuth 1.0 is deprecated (see https://developers.google.com/accounts/docs/OAuth), velruse would benefit from a OAuth 2.0 implementation for Google (https://developers.google.com/accounts/docs/OAuth2). It is also much easier to implement and maintain than the OpenID + OAuth hybrid.
I have written a provider called "google2" in my branch (https://github.com/naktinis/velruse/commit/7c75a1c01e68d64b218d83cbfa29df7994ce9371) if it would be of any help. I can create a pull request, or simply leave it to you as a working example.