On Tue, Mar 31, 2015 at 8:57 PM, Bruno Oliveira <bruno@abstractj.org> wrote:I'm sorry if I'm late for the discussion, but I will voice my concerns anyways.1. I don't see the real need/use case/scenario to support OAuth1. I'm not saying that OAuth1 is bad, but currently even after reading the GSoC proposal, I can't see which problem we're trying to solve here.2. The big win of our APIs, is the extensibility. In my mind is: implement by your own if our SDK don't have it. If we're willing to maintain 2 protocols + OAuth1/2 providers outside, I'm a bit concerned about the bandwidth to maintain this codebase.By that I mean, not only writing the code, but keep an eye on the vulnerabilities from an OAuth1 provider located in Springfield, for example. Because someone thought would be cool to support The Simpsons.3. I think we have to be cautious about not reinvent the wheel. Several SDKs for social already the job for most of the popular APIs outside.yes, for JS we agreed to not create any social provider support, since they exist already (and why would I as a Twitter developer use a provider from somewhere else).So for iOS I agree that initial work to move the FB/Google providers out, as discussed on thread you reference under [1], but I am not really seeing us moving towards a social framework nor as a provider for several social networks.4. Our APIs are pretty much in a good shape, but there's always a room for improvements. If we suggest to people to improve the already existent APIs, instead of creating new ones, that in my personal opinion would be a good GSoC proposal.I like that idea and looking here https://aerogear.org/docs/guides/security/oauth2-guide/#_overview perhaps the we should change the subject and really improve the feature set, and improve existing API.If the student wants to leverage the work for a specific social network of choice, as a test-case, that's fine - but I am not sure if adding support for yet another social network really makes sense.This is only my 2 cents. I think we should make our SDKs stronger, than they already are, instead of implement more stuff without a good reason.On Tue, Mar 31, 2015 at 9:58 AM, Luke Holmquist <lholmqui@redhat.com> wrote:On Thu, Mar 26, 2015 at 2:09 PM, Matthias Wessendorf <matzew@apache.org> wrote:
On Thursday, March 26, 2015, Corinne Krych <corinnekrych@gmail.com> wrote:
> On 26 Mar 2015, at 17:25, Matthias Wessendorf <matzew@apache.org> wrote:
>
>
>
> On Wed, Mar 25, 2015 at 5:03 PM, Corinne Krych <corinnekrych@gmail.com> wrote:
> Hello All,
>
> As discussed in this thread [1], we are going to create an aerogear-ios-social repository to host FacebookConfig... etc. When it’s specific to a provider it will go in social.
>
> +1
>
> but I don't get why we now also work on support for OAuth1
aerogear-ios-social will be part of GSoC, this PRs are to prepare the work our student will do. I’ve created the JIRAs for that.
To have a proper social library we need to have both OAuth1 and 2.
Similar approach for oauth / http integration.
Our oauth1 lib should eventually use aerogear-ios-crypto.I am not sure if we really should put a lot of effort on a proper social lib, including oauth2. A bit surprised this is included in 2.3I sort of agree with this.I was wondering why we need this exactly? Don't the native platforms(iOS, Android) already have SDK's and integration with FB, G+, and twitter already.i know this is a major reason why the JS lib isn't planning a social lib. Those libs already exist--
>
> -Matthias
>
> Social lib work is tracked under epic AGIOS-409 [2]. We also have a GSoC [2] for the iOS social lib so hopefully we’ll have some help here ;)
>
> As a first step toward Social framework, AGIOS-419 provides support for OAuth1.
> Here is a list of related PRs to review together:
> - ios-http: https://github.com/aerogear/aerogear-ios-http/pull/40
> - ios-oauth2: https://github.com/aerogear/aerogear-ios-oauth2/pull/26
> - ios-oauth1: https://github.com/corinnekrych/aerogear-ios-oauth1
>
> The cookbook demo app [3] (which eventually will use ios-social pod) uses Twitter and can be used to test the PRs.
>
> PR review and comments welcome!
>
> ++
> Corinne
> [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Android-Refactoring-OAuth2-configuration-td11113.html
> [2] https://developer.jboss.org/wiki/GSOC15Ideas#jive_content_id_Go_Social
> [3] https://github.com/corinnekrych/aerogear-ios-cookbook-1/tree/incognito/Incognito
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Sent from Gmail Mobile
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev----
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev--Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf