[aerogear-dev] Cordova Ouath2 plugin using Google Play Services
Summers Pittman
supittma at redhat.com
Thu Feb 26 10:13:13 EST 2015
On 02/26/2015 02:13 AM, Brian Leathem wrote:
>
> One way to make this work would be to move the Aerogear Oauth2 API
> altogether to an intent based one. Users would start an intent to
> retrieve an Oauth2 token, which we would deliver to their
> #onActivityResult method, regardless of the mechanism we use.
>
> This would also allow us to resolve AGDROID-319 elegantly.
>
Yup. I made 319 while trying to do what you are currently doing.
I really, really, REALLY wish Google hadn't made Android a class and had
gone for an injection/composition programming model instead. It's like
they weren't even paying any attention to academic and professional
literature about OO and Java in 2006...
> Hello all,
>
> So I've gotten pretty close in my implementation, but I've got one
> blocker:
>
> The account selection and Oath2 token request are initiated using an
> intent. The result is then retrieved by implementing the
> #onActivityResult method of the initial activity. The problem I'm
> facing is the original activity exists in the user's application.
> Nesting activities isn't a solution, as I still don't have access to
> the top-level activity.
>
> Implementing this purely as a cordova plugin is trivial, as I can just
> @Override the #onActivityResult of the CordovaPlugin class.
>
> Do any Android experts have a recommendation on how I can implement
> this as a generic Android library in android-authz?
>
> Alternatively if we implement this directly in the oauth2-codova
> plugin I have everything we need already complete.
>
> Brian
>
> On 2015-02-25 10:44 AM, Daniel Passos wrote:
>>
>> Hey Brian,
>>
>> You can. but not necessarily need do that.. You can create your own
>> workflow.
>>
>> Just implement your own:
>>
>> *
>>
>> OAuth2AuthroizationConfigurationProvider
>>
>> *
>>
>> AuthorizationConfiguration
>>
>> * AuthzModule.java
>>
>> And let the |AuthorizationManager| know[1] your new Authz
>>
>> |AuthorizationManager.registerConfigurationProvider(YourNewAuthorizationConfiguration, new YourNewOAuth2AuthroizationConfigurationProvider)
>> |
>>
>> [1]
>> https://github.com/aerogear/aerogear-android-authz/blob/master/aerogear-android-authz/src/main/java/org/jboss/aerogear/android/authorization/AuthorizationManager.java#L37-L41
>>
>> -- Passos
>>
>>
>>
>>
>> On Wed, Feb 25, 2015 at 3:30 PM, Brian Leathem <bleathem at gmail.com
>> <mailto:bleathem at gmail.com>> wrote:
>>
>> ... and the devil is in the details.
>>
>> It seems as though all the current AuzthzModules use an http
>> based approach to requesting an Oauth2 token. I see this being
>> done in OAuth2WebFragmentFetchAutorization#doAuthorization
>> method, where an OAuthWebViewDialog is used to trigger the Oauth2
>> token request.
>>
>> To use Google Play services to trigger an Oauth2 token request,
>> we won't use an http approach, but rather we start an activity to
>> select an account and request an Oauth2 token. Once the token is
>> retrieved it can then be used with the standard http Oauth2 API.
>>
>> (One caveat: the google play services token response doesn't
>> provide a refresh token. I believe this to be a non-issue as the
>> token request process is trivial when using google play services
>> (no authentication step)).
>>
>> I see to ways to implement this feature:
>>
>> 1) Generalize the OAuth2WebFragmentFetchAutorization into an
>> interface, and have one implementation to handle http-based token
>> requests, and second implementation to handle intent-based token
>> requests.
>>
>> 2) Add a OAuth2AuthorizationConfiguration option to use intents
>> instead of http, and trigger a different workflow within the
>> OAuth2WebFragmentFetchAutorization#doAuthorization method if that
>> config is set.
>>
>> My preference is for 2) because it's a) simpler, and b) it is
>> really only during the #doAuthorization method that we have a
>> different approach.
>>
>> Thoughts? I'll start with implementing approach (2) unless I
>> hear otherwise.
>>
>> Brian
>>
>>
>> On 2015-02-24 07:25 PM, Matthias Wessendorf wrote:
>>>
>>>
>>> On Wednesday, February 25, 2015, Daniel Passos <daniel at passos.me
>>> <mailto:daniel at passos.me>> wrote:
>>>
>>> No, we are not using Google Play services API for now for
>>> OAuth2 in Android land.
>>>
>>> But feel free create a new AuthzModule[1] for it ;)
>>>
>>>
>>> +1
>>>
>>>
>>> [1]
>>> https://github.com/aerogear/aerogear-android-authz/blob/master/aerogear-android-authz/src/main/java/org/jboss/aerogear/android/authorization/AuthzModule.java
>>>
>>> -- Passos
>>>
>>>
>>> On Tue, Feb 24, 2015 at 4:01 PM, Sebastien Blanc
>>> <scm.blanc at gmail.com> wrote:
>>>
>>> Cool stuff Brian !
>>> The AeroGear OAuth2 Cordova plugin relies on the Native
>>> AeroGear OAuth2 Libraries, so maybe Summers and/or
>>> Daniel could tell more about it.
>>> Sebi
>>>
>>> On Tue, Feb 24, 2015 at 7:46 PM, Brian Leathem
>>> <bleathem at gmail.com> wrote:
>>>
>>> Hey gear-heads,
>>>
>>> I recently wrote a Cordova plugin that retrieves a
>>> Oauth2 token on
>>> Android using Google Play Services. The advantage
>>> of this approach is
>>> it leverages the single-sign-on capabilities of
>>> android, and the app can
>>> retrieve the Oauth2 token without requiring
>>> Authentication from the
>>> user. I blogged about it here:
>>>
>>> http://www.bleathem.ca/blog/2015/02/cordova-oauth-google-services.html
>>>
>>> Using a promise-based API it's fairly trivial to
>>> fallback to a
>>> traditional Web authentication/authorisation for the
>>> Oauth2 token when
>>> the google-play-services approach isn't supported.
>>>
>>> I'm aware the aerogear team has a Oauth2 cordova
>>> plugin [1], but it's
>>> not clear to me if the google-play-services
>>> integration is supported.
>>> If the Aerogeam would find it useful, I'd be more
>>> than happy to provide
>>> a PR to the aerogear cordova plugin providing such
>>> integration.
>>>
>>> Thoughts?
>>> Brian
>>>
>>> [1]
>>> http://staging-aerogearsite.rhcloud.com/docs/specs/aerogear-cordova/OAuth2.html
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>>
>>>
>>> --
>>> Sent from Gmail Mobile
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150226/ca101b21/attachment-0001.html
More information about the aerogear-dev
mailing list