Re: [aerogear-dev] [Android] - Refactoring OAuth2 configuration

On 2015-03-10, Matthias Wessendorf wrote: > On Mon, Mar 9, 2015 at 5:56 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: > > > On 03/09/2015 12:50 PM, Matthias Wessendorf wrote: > > > > > > > > On Mon, Mar 9, 2015 at 5:34 PM, Summers Pittman <supittma(a)redhat.com&gt; > > wrote: > > > >> On 03/09/2015 12:15 PM, Erik Jan de Wit wrote: > >> >> Because Facebook and Google are well known for not making arbitrary > >> changes to public apis and configurations. > >> >> > >> >> More importantly as an Open Source project hitching our code to the > >> configuration of a third party proprietary system is terrifyingly bad > >> karma. Push is an exception ONLY because there isn't an equvalent open > >> solution which has the same reach to devices. > >> > It’s just some configuration, what point does oauth2 have when it > >> doesn’t work with Facebook and Google. > >> /me looks at the shoot and share demo, and the gdrive demo. > >> Looks like it does work with FB and Google. Did you have a specific > >> example in mind? > >> > The whole point of our libs is to make it easy for developers to do > >> these complex things adding this config makes it super easy. I don’t see: > >> ”Terrifyingly bad karma” a good reason not to do this. > >> Because it is hitching our open source project to the largess of > >> proprietary service vendors. If they change THEIR configuration and OUR > >> libraries break WE look like the bad guys not them for starters. > >> > > > > That happened with push (Google's documentation, not the APIs) in the > > past, and may happen again. We reacted pretty quick on that one, which is > > what matters. If we would not react, we would look bad. > > > > Perhaps we can add a statement that the code executes against a 3rd > > party service, that we don't own. That can even happen with differen > > Keycloak versions. However, usually actual API changes from the big players > > are usually announced, and it's usually comes with a little bit of time to > > react. > > > > > >> > >> Additionally the only direction this can go is toward scope creep. Once > >> we have Facebook and Google nothing is stopping (rhetorically) from > >> adding Facebook, Yahoo, VK, Microsoft, etc. Now we are maintaining 5x > >> as many configurations as we were before. > > > > > > I'd not add more, out of the blue. But if there is demand (from which > > ever direction), it's time to react on that demand, but not before > > > > > >> Who is going to monitor those > >> APIs and make sure they don't break/get deprecated? Do we cut a release > >> because one auth provider changed their config? > >> > >> Of course we don't because that is the responsibility of the app > >> developer to make sure their configuration for the services they consume > >> is up to date. It is not and should not be our responsibility. > >> > >> I freely admit it is nice and it is convenient but it does not belong in > >> the project. > >> > > > > Instead, we don't offer any concrete impls for Google or Facebook? > > > > Correct > > > > Or use a complicated and generic API, which may work, or not? > > > > The API works as long as the service correctly implements and documents > > their OAuth2 parameters. > > > > I don't see how providing the OAuth2 parameters required by the > > specification we implement makes this a complex API. It is 2 fields > > (client id and client secret) per client and 5 fields (the various > > endpoints and base urls) per service. > > > > > Should we provide guides or tutorials, how to use the generic API against a > very few (e.g. FB and Google) services ? I'm already doing it, please see AGSEC-200

> > > > > > > > > >> > >> > >> > > >> > > >> > _______________________________________________ > >> > aerogear-dev mailing list > >> > aerogear-dev(a)lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> > >> -- > >> Summers Pittman > >> >>Phone:404 941 4698 > >> >>Java is my crack. > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev(a)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 listaerogear-dev@lists.jboss.orghttps:// lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > -- > > Summers Pittman > > >>Phone:404 941 4698 > > >>Java is my crack. > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev