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
<mailto:supittma@redhat.com>> 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.
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@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 <mailto: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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Summers Pittman
>Phone:404 941 4698
>Java is my crack.