Pre-announcement for AeroGear-iOS 1.6
by Corinne Krych
Hello iOS guys and ladies,
We’ve been working toward AeroGear-iOS 1.6 release (planned mid-June), we’re almost there! Most PRs have been merged. So if you want to give it a spin and shared feedback, we’ll appreciate all hands. If everything goes smoothly we should tag and publish 1.6 by Thursday next week.
Last words, the main focus of 1.6 is on OAuth2, so be social, spread the word :)
Corinne && Christos
10 years, 8 months
OAuth2 and Account Management
by Corinne Krych
Hello all
It all started in that thread [1] talking about Android OAuth2 PR, but the discussion shifted on account management and storage. I think AccountManager deserves its own thread besides it’s a cross client topic (although implicit grant for pure web app is less a use case) so title is not right. Let’s fork the discussion.
Main goal of AccountManager is to store all the social access tokens per account. Here is the use case:
Some application may have to deal with several OAuth2 providers. For example in ios-cookbook, we have Shoot app which let you upload your photos to Google Drive(should change that to Google+ eventually), Facebook (and soon Instagram). When a user open Shoot for the first time and want to share to facebook, he will be prompted for OAuth2 grant, same thing for Google grant. The second photo will not trigger any grant as we’ve got the tokens. But if a user close the app and reopen it, we need something to store them if we don’t want to prompt again => AccountManager.
Encrypted or not encrypted?
Obviously access token and even more refresh token are sensitive data. Should we store them encrypted or in a secure storage like KeyChain or KeyStore? If we go that path a password is required to encrypt or access keychain, so we need an extra prompt for the user to enter password. For example, we can chage Shoot to require a password at first login to ancrypt/decrypt access token.
I would leave this decision to the end-use rdeveloper of the app. I would go for a configurable AccountManager, being able to take a store as demo here [2].
For now proposed API:
As explained here [3], use same method signature authz: like for AGAuthorizer. But when use on AccountManager it will create a authzModule and add an account to store tokens.
What’s next?
We need to be able to revoke tokens and remove account from account manager.
Thoughts?
@summers : as you’re the guy behind Account Manager, if you can have a look to iOS PR [2] [3] I would love to hear about your thoughts
++
Corinne
[1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Android-OAuth2-PR-...
[2] https://github.com/corinnekrych/aerogear-ios-cookbook-1/blob/AGIOS-190.ac...
[3] https://github.com/corinnekrych/aerogear-ios-cookbook-1/blob/AGIOS-190.ac...
10 years, 8 months
AeroGear UnifiedPush Server
by Jeffrey Quiatchon
Hello,
Just want to know you guys that your product was very good enough to
deliver the needs of push notification in multiple platform.
I would like to ask if you have any documentation regarding the step by
step installation of AeroGear UnifiedPush in Ubuntu 12.04.4 LTS?
Thank you so much
10 years, 8 months
Question about iOS 6
by René Smits
Hello,
I just succeed to install and configure a aerogear push server and used it successfully on a android device.
The next step is an iOS device, i’ve got the demo app deployed on a ipod 4 with iOS 6.1.2 but it crashed.
It looks like you need IOS 7 for the aerogear push library 0.9.1?
Is it possible to deploy to IOS 6? Can i use an older version of the library, which one should i use?
It it not possible to upgrade the ipod to iOS 7.
Regards,
René Smits
10 years, 8 months
Observations on iOS OAuth
by Yagyesh
I have few observations & suggestions based on the time i spent with OAuth
related code in Aerogear iOS library:
1.
Below is the code snippet from authz method of AGAuthorizer.m:
————————
if(![authzConfig.type isEqualToString:@"AG_OAUTH2_FACEBOOK"] &&
![authzConfig.type isEqualToString:@"AG_OAUTH2"])
return nil;
authzConfig.type = [self oauth2Type:authzConfig];
————————
As ‘type’ property is exposed to developers & they may set it in their code,
i feel changing it without giving any info/warning will not be appreciated
by the developers.
2.
Also, since ‘type’ is exposed, we can also completely eliminate the need for
setting the correct type via oauth2type method. The list of supported types
can be exposed as string constants or enum, & developers can choose to set
the type based on their requirements. In authz method, we can simply assert
with proper message if type is not set. In my opinion, oauth2type method is
anyways not very robust in determining the correct type & may need to be
changed constantly as we add support for more oauth providers. Also, for
instance if facebook changes the authentication end point and access end
point to use to a common base url, oauth2type method may fail in determining
correct type. This is just an example and probably facebook may never change
anything. But the point i'm trying to make is that allowing developers to
set the type will avoid any issues like this.
3.
Similarly, setting default values in init method of AGAuthzConfiguration.m
is also not very useful. As default values will not work if developers do
not set all the relevant config properties. And since we are setting
defaults, we could not assert to developers in case any mandatory property
is not set.
4.
If we do want to set defaults, we should have defaults specific to modules.
For example, Facebook OAuth should have its own set of default values for
authzEndPoint, accessTokenEndPoint, revokeEndPoint etc. As values for these
properties may not change with applications, even if developers forget to
set these properties things may just work for them out of the box in most
cases.
5.
We can have asserts for all mandatory properties that are not set.
Let me know what do you guys think about these.
--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Observations-on-iOS-OAuth-tp813...
Sent from the aerogear-dev mailing list archive at Nabble.com.
10 years, 8 months
UnifiedPush server - Staging dates
by Bruno Oliveira
Good morning,
I would like to stage the Push server on Friday (13 Jun) or Monday (16
Jun). What do you think?
--
abstractj
10 years, 8 months
Possible error in oauth2Type method in AGAuthorizer.m
by Yagyesh
I'm working on an example using auth functionality of AeroGear. The method
oauth2Type is currently implemented as follows:
- (NSString*)oauth2Type:(AGAuthzConfiguration*)config {
if ([*config.authzEndpoint* rangeOfString:@"facebook"].location !=
NSNotFound) {
return @"AG_OAUTH2_FACEBOOK";
}
return @"AG_OAUTH2";
}
Now, config.authzEndpoint will have values like "/o/oauth2/auth" or maybe
"/dialog/oauth" in case of facebook. Thus the check above will always result
in false & the return type will always be "AG_OAUTH2".
Shouldnt the method be instead checking *config.baseURL.host* ?
--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Possible-error-in-oauth2Type-me...
Sent from the aerogear-dev mailing list archive at Nabble.com.
10 years, 8 months
Improving Android HelloPush demo experience in Eclipse - PR
by Karel Piwko
Hi All,
I went through Android demo (and JBDS) and created following PR:
https://github.com/aerogear/aerogear-push-helloworld/pull/18
Let me know if you want to have separate PRs per commit. Goal was to have
example working in Eclipse/JBDS + ADT. There is still manual steps to do and
an error I was not able to fix it completely, investigating.
As per commit:
1/ Fixes Eclipse error marker for maven-android-plugin. AAR is not used, so it
is fine.
2/ Quickstart/demos should not have any parent, Maven best practice. Check JDF
quickstarts. Quickstart is an example and it is used to by user to scaffold
their own apps. We don't want them to use ag-parent but just ag-bom.
3/ If project.properties is missing, Eclipse is not able to add Android SDK to
build path. I've set it to API 19. This means that user has to point ADT to
Android SDK with API 19 installed. This is also version Eclipse will use for
code suggestion/autocompletion/build in IDE. Should have been API 10, I'm not
sure here.
4/ Dependencies in <dependencyManagement> should not define any scope with
exception of *import*. Maven best practice.
5/ If user don't provide UNIFIED_PUSH_URL, application fails due to
RuntimeException. I've added catch for IAE and Toast, however I believe there
should be a better way how to indicate that to user. IAE is quite generic and
fired from URLUtils in GCM registar. I'll file an issue to improve that.
6/ /bin directory is used by default by Eclipse to host temporary build
After these steps, I needed to follow these manual steps:
a/ Import android-support-v7-appcompat from Android SDK into workspace as
Android project
b/ Import hellopush/android as Maven project
c/ Add android-support-v7-appcompat as library in Android tab of project
properties
Now, I can edit the code. However, I can't use Run As/Android
Application still, likely due to http://tinypic.com/r/260ejpl/8
I'd appreciate if somebody could verify it is still working with AndroidStudio.
Thanks,
Karel
10 years, 8 months
