8:42 a.m.
Good morning, while writing our quickstarts, I found something that I
would like to change.
Currently to setup our OAuth2 providers we have to do something like
this:
AuthorizationManager.config(MODULE_NAME, OAuth2AuthorizationConfiguration.class)
.setBaseURL(new URL("https://"))
.setAuthzEndpoint(AUTHZ_ENDPOINT)
.setAccessTokenEndpoint(AUTHZ_TOKEN_ENDPOINT)
.setAccountId(AUTHZ_ACCOOUNT_ID)
.setClientId(AUTHZ_CLIENT_ID)
.setClientSecret(AUTHZ_CLIENT_SECRET)
.setRedirectURL(AUTHZ_REDIRECT_URL)
.setRefreshEndpoint(AUTHZ_TOKEN_ENDPOINT)
.addAdditionalAccessParam(Pair.create("response_type",
"code"))
.setScopes(Arrays.asList("photo_upload, publish_actions"))
.asModule();
Although, things like the url endpoint, access token endpoint, or the
module will most of time remain unchanged. Unless you switch from Facebook to
Keycloak for example. People don't care that much about these
urls, but which provider they want to connect.
So I would like to refactor the authz module from AGDroid, define the default values
for ommitted params and make the methods like setBaseURL for example,
alternative. Something like this:
AuthorizationManager.config(MODULE_NAME, OAuth2AuthorizationConfiguration.class)
.setClientId(AUTHZ_CLIENT_ID)
.setClientSecret(AUTHZ_CLIENT_SECRET)
.asModule();
Based on the module name, we instantiate the respective module with the
default values already in.
Thoughts? Let me know if the idea is useless.
--
abstractj
PGP: 0x84DC9914
9 a.m.
+1 that would make it more in sync with iOS and Windows, where we created profiled
config:
https://github.com/aerogear/aerogear-windows-oauth2/blob/master/aerogear-...
<https://github.com/aerogear/aerogear-windows-oauth2/blob/master/aerogear-...
https://github.com/aerogear/aerogear-ios-oauth2/blob/master/AeroGearOAuth...
<https://github.com/aerogear/aerogear-ios-oauth2/blob/master/AeroGearOAuth...
On 9 Mar,2015, at 14:42 , Bruno Oliveira <bruno(a)abstractj.org>
wrote:
Good morning, while writing our quickstarts, I found something that I
would like to change.
Currently to setup our OAuth2 providers we have to do something like
this:
AuthorizationManager.config(MODULE_NAME, OAuth2AuthorizationConfiguration.class)
.setBaseURL(new URL("https://"))
.setAuthzEndpoint(AUTHZ_ENDPOINT)
.setAccessTokenEndpoint(AUTHZ_TOKEN_ENDPOINT)
.setAccountId(AUTHZ_ACCOOUNT_ID)
.setClientId(AUTHZ_CLIENT_ID)
.setClientSecret(AUTHZ_CLIENT_SECRET)
.setRedirectURL(AUTHZ_REDIRECT_URL)
.setRefreshEndpoint(AUTHZ_TOKEN_ENDPOINT)
.addAdditionalAccessParam(Pair.create("response_type",
"code"))
.setScopes(Arrays.asList("photo_upload, publish_actions"))
.asModule();
Although, things like the url endpoint, access token endpoint, or the
module will most of time remain unchanged. Unless you switch from Facebook to
Keycloak for example. People don't care that much about these
urls, but which provider they want to connect.
So I would like to refactor the authz module from AGDroid, define the default values
for ommitted params and make the methods like setBaseURL for example,
alternative. Something like this:
AuthorizationManager.config(MODULE_NAME, OAuth2AuthorizationConfiguration.class)
.setClientId(AUTHZ_CLIENT_ID)
.setClientSecret(AUTHZ_CLIENT_SECRET)
.asModule();
Based on the module name, we instantiate the respective module with the
default values already in.
Thoughts? Let me know if the idea is useless.
--
abstractj
PGP: 0x84DC9914
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
9:21 a.m.
+1
++
Corinne
On 09 Mar 2015, at 15:00, Erik Jan de Wit <edewit(a)redhat.com>
wrote:
+1 that would make it more in sync with iOS and Windows, where we created profiled
config:
https://github.com/aerogear/aerogear-windows-oauth2/blob/master/aerogear-...
https://github.com/aerogear/aerogear-ios-oauth2/blob/master/AeroGearOAuth...
> On 9 Mar,2015, at 14:42 , Bruno Oliveira <bruno(a)abstractj.org> wrote:
>
> Good morning, while writing our quickstarts, I found something that I
> would like to change.
>
> Currently to setup our OAuth2 providers we have to do something like
> this:
>
> AuthorizationManager.config(MODULE_NAME, OAuth2AuthorizationConfiguration.class)
> .setBaseURL(new URL("https://"))
> .setAuthzEndpoint(AUTHZ_ENDPOINT)
> .setAccessTokenEndpoint(AUTHZ_TOKEN_ENDPOINT)
> .setAccountId(AUTHZ_ACCOOUNT_ID)
> .setClientId(AUTHZ_CLIENT_ID)
> .setClientSecret(AUTHZ_CLIENT_SECRET)
> .setRedirectURL(AUTHZ_REDIRECT_URL)
> .setRefreshEndpoint(AUTHZ_TOKEN_ENDPOINT)
> .addAdditionalAccessParam(Pair.create("response_type",
"code"))
> .setScopes(Arrays.asList("photo_upload, publish_actions"))
> .asModule();
>
> Although, things like the url endpoint, access token endpoint, or the
> module will most of time remain unchanged. Unless you switch from Facebook to
> Keycloak for example. People don't care that much about these
> urls, but which provider they want to connect.
>
> So I would like to refactor the authz module from AGDroid, define the default values
> for ommitted params and make the methods like setBaseURL for example,
> alternative. Something like this:
>
> AuthorizationManager.config(MODULE_NAME, OAuth2AuthorizationConfiguration.class)
> .setClientId(AUTHZ_CLIENT_ID)
> .setClientSecret(AUTHZ_CLIENT_SECRET)
> .asModule();
>
> Based on the module name, we instantiate the respective module with the
> default values already in.
>
> Thoughts? Let me know if the idea is useless.
>
>
> --
>
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
11:20 a.m.
On Mon, Mar 9, 2015 at 3:00 PM, Erik Jan de Wit <edewit(a)redhat.com> wrote:
+1 that would make it more in sync with iOS and Windows, where we
created
profiled config:
https://github.com/aerogear/aerogear-windows-oauth2/blob/master/aerogear-...
https://github.com/aerogear/aerogear-ios-oauth2/blob/master/AeroGearOAuth...
I think these _are_ good examples of specific configuration options for
different 3rd party services
On 9 Mar,2015, at 14:42 , Bruno Oliveira <bruno(a)abstractj.org> wrote:
Good morning, while writing our quickstarts, I found something that I
would like to change.
Currently to setup our OAuth2 providers we have to do something like
this:
AuthorizationManager.config(MODULE_NAME,
OAuth2AuthorizationConfiguration.class)
.setBaseURL(new URL("https://"))
.setAuthzEndpoint(AUTHZ_ENDPOINT)
.setAccessTokenEndpoint(AUTHZ_TOKEN_ENDPOINT)
.setAccountId(AUTHZ_ACCOOUNT_ID)
.setClientId(AUTHZ_CLIENT_ID)
.setClientSecret(AUTHZ_CLIENT_SECRET)
.setRedirectURL(AUTHZ_REDIRECT_URL)
.setRefreshEndpoint(AUTHZ_TOKEN_ENDPOINT)
.addAdditionalAccessParam(Pair.create("response_type",
"code"))
.setScopes(Arrays.asList("photo_upload, publish_actions"))
.asModule();
Although, things like the url endpoint, access token endpoint, or the
module will most of time remain unchanged. Unless you switch from Facebook
to
Keycloak for example. People don't care that much about these
urls, but which provider they want to connect.
So I would like to refactor the authz module from AGDroid, define the
default values
for ommitted params and make the methods like setBaseURL for example,
alternative. Something like this:
AuthorizationManager.config(MODULE_NAME,
OAuth2AuthorizationConfiguration.class)
.setClientId(AUTHZ_CLIENT_ID)
.setClientSecret(AUTHZ_CLIENT_SECRET)
.asModule();
Based on the module name, we instantiate the respective module with the
default values already in.
Thoughts? Let me know if the idea is useless.
--
abstractj
PGP: 0x84DC9914
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
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
9:59 a.m.
On 03/09/2015 09:42 AM, Bruno Oliveira wrote:
Good morning, while writing our quickstarts, I found something that
I
would like to change.
Currently to setup our OAuth2 providers we have to do something like
this:
AuthorizationManager.config(MODULE_NAME, OAuth2AuthorizationConfiguration.class)
.setBaseURL(new URL("https://"))
.setAuthzEndpoint(AUTHZ_ENDPOINT)
.setAccessTokenEndpoint(AUTHZ_TOKEN_ENDPOINT)
.setAccountId(AUTHZ_ACCOOUNT_ID)
.setClientId(AUTHZ_CLIENT_ID)
.setClientSecret(AUTHZ_CLIENT_SECRET)
.setRedirectURL(AUTHZ_REDIRECT_URL)
.setRefreshEndpoint(AUTHZ_TOKEN_ENDPOINT)
.addAdditionalAccessParam(Pair.create("response_type",
"code"))
.setScopes(Arrays.asList("photo_upload, publish_actions"))
.asModule();
Although, things like the url endpoint, access token endpoint, or the
module will most of time remain unchanged. Unless you switch from Facebook to
Keycloak for example. People don't care that much about these
urls, but which provider they want to connect.
So I would like to refactor the authz module from AGDroid, define the default values
for ommitted params and make the methods like setBaseURL for example,
alternative. Something like this:
AuthorizationManager.config(MODULE_NAME, OAuth2AuthorizationConfiguration.class)
.setClientId(AUTHZ_CLIENT_ID)
.setClientSecret(AUTHZ_CLIENT_SECRET)
.asModule();
Based on the module name, we instantiate the respective module with the
default values already in.
Thoughts? Let me know if the idea is useless.
The thought of supporting vendor
specific configuration details makes me
cringe.
--
abstractj
PGP: 0x84DC9914
_______________________________________________
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.
10:08 a.m.
On 09 Mar 2015, at 16:06, Erik Jan de Wit <edewit(a)redhat.com>
wrote:
>>
>> Thoughts? Let me know if the idea is useless.
> The thought of supporting vendor specific configuration details makes me
> cringe.
It convenient and not likely to change
Eventually i’m planning to move those provider specific configuration into Social fwk sub
podspec
and let the use choose to add then or not to its podfile
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
10:11 a.m.
On 03/09/2015 11:06 AM, Erik Jan de Wit wrote:
>>
>> Thoughts? Let me know if the idea is useless.
> The thought of supporting vendor specific configuration details makes me
> cringe.
It convenient and not likely to change
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.
_______________________________________________
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.
10:21 a.m.
As suggested make it part of Social lib then.
I’d love to see some convergence in our oauth libs
For example:
- why not naming aerogear-android-authz by aerogear-android-oauth2 like all other libs?
- why not propose a intent based (i.e.: external browser) implementation for android?
++
Corinne
On 09 Mar 2015, at 16:11, Summers Pittman <supittma(a)redhat.com>
wrote:
oject 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 devic
10:50 a.m.
On 03/09/2015 11:21 AM, Corinne Krych wrote:
As suggested make it part of Social lib then.
I’d love to see some convergence in our oauth libs
For example:
- why not naming aerogear-android-authz by aerogear-android-oauth2 like all other libs?
Because we have multiple JIRA tasks for supporting things other than oauth.
- why not propose a intent based (i.e.: external browser)
implementation for android?
There's a JIRA for that too.
++
Corinne
> On 09 Mar 2015, at 16:11, Summers Pittman <supittma(a)redhat.com> wrote:
>
> oject 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 devic
_______________________________________________
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.
11:23 a.m.
On Mon, Mar 9, 2015 at 4:50 PM, Summers Pittman <supittma(a)redhat.com> wrote:
On 03/09/2015 11:21 AM, Corinne Krych wrote:
> As suggested make it part of Social lib then.
> I’d love to see some convergence in our oauth libs
>
> For example:
> - why not naming aerogear-android-authz by aerogear-android-oauth2 like
all other libs?
Because we have multiple JIRA tasks for supporting things other than oauth.
Could these 'things other than oauth' live in its own repo? Or is the idea
to be modular inside of the authz repo?
> - why not propose a intent based (i.e.: external browser)
implementation
for android?
There's a JIRA for that too.
>
> ++
> Corinne
>
>> On 09 Mar 2015, at 16:11, Summers Pittman <supittma(a)redhat.com> wrote:
>>
>> oject 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
devic
>
> _______________________________________________
> 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
11:27 a.m.
On 03/09/2015 12:23 PM, Matthias Wessendorf wrote:
On Mon, Mar 9, 2015 at 4:50 PM, Summers Pittman <supittma(a)redhat.com
<mailto:supittma@redhat.com>> wrote:
On 03/09/2015 11:21 AM, Corinne Krych wrote:
> As suggested make it part of Social lib then.
> I’d love to see some convergence in our oauth libs
>
> For example:
> - why not naming aerogear-android-authz by
aerogear-android-oauth2 like all other libs?
Because we have multiple JIRA tasks for supporting things other
than oauth.
Could these 'things other than oauth' live in its own repo? Or is the
idea to be modular inside of the authz repo?
the idea to be modular inside of the
authz repo
> - why not propose a intent based (i.e.: external browser) implementation for
android?
There's a JIRA for that too.
>
> ++
> Corinne
>
>> On 09 Mar 2015, at 16:11, Summers Pittman <supittma(a)redhat.com
<mailto:supittma@redhat.com>> wrote:
>>
>> oject 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 devic
>
> _______________________________________________
> 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.
10:51 a.m.
Second attempt before giving up. What about have something like:
<meta-data android:name="org.aerogear.auth.baseUrl"
android:value="https://"/>
<meta-data android:name="org.aerogear.auth.endpoint"
android:value="myauthendpoint"/>
<meta-data android:name="org.aerogear.auth.accessTokenEndpoint"
android:value="myauthendpoint"/>
Not attached to any provider, easy for us to provide snippets for cut
and paste and we leave in the classe only what matters most. Wdyt?
If that's not a thing, never mind.
On 2015-03-09, Summers Pittman wrote:
On 03/09/2015 11:06 AM, Erik Jan de Wit wrote:
>>>
>>>Thoughts? Let me know if the idea is useless.
>>The thought of supporting vendor specific configuration details makes me
>>cringe.
>
>
>It convenient and not likely to change
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.
>
>_______________________________________________
>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
--
abstractj
PGP: 0x84DC9914
10:55 a.m.
On 03/09/2015 11:51 AM, Bruno Oliveira wrote:
Second attempt before giving up. What about have something like:
<meta-data android:name="org.aerogear.auth.baseUrl"
android:value="https://"/>
<meta-data android:name="org.aerogear.auth.endpoint"
android:value="myauthendpoint"/>
<meta-data android:name="org.aerogear.auth.accessTokenEndpoint"
android:value="myauthendpoint"/>
Not attached to any provider, easy for us to provide snippets for cut
and paste and we leave in the classe only what matters most. Wdyt?
That's
pretty much how Android android.app.Authenticator works.
Basically we would define a service, pass in the oauth2 information and
then have the activity do its magic.
If that's not a thing, never mind.
On 2015-03-09, Summers Pittman wrote:
> On 03/09/2015 11:06 AM, Erik Jan de Wit wrote:
>>>> Thoughts? Let me know if the idea is useless.
>>> The thought of supporting vendor specific configuration details makes me
>>> cringe.
>>
>> It convenient and not likely to change
> 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.
>
>> _______________________________________________
>> 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
--
abstractj
PGP: 0x84DC9914
_______________________________________________
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.
11:15 a.m.
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. 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.
11:34 a.m.
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.
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. 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.
_______________________________________________
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.
11:50 a.m.
On Mon, Mar 9, 2015 at 5:34 PM, Summers Pittman <supittma(a)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? Or use a
complicated and generic API, which may work, or not?
>
>
> _______________________________________________
> 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
11:56 a.m.
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.
3:15 a.m.
On Mon, Mar 9, 2015 at 5:56 PM, Summers Pittman <supittma(a)redhat.com> 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>
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 ?
>
>
> >
> >
> > _______________________________________________
> > 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
7:02 a.m.
On 2015-03-10, Matthias Wessendorf wrote:
On Mon, Mar 9, 2015 at 5:56 PM, Summers Pittman
<supittma(a)redhat.com> 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>
> 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
7:17 a.m.
On Tue, Mar 10, 2015 at 1:02 PM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
On 2015-03-10, Matthias Wessendorf wrote:
> On Mon, Mar 9, 2015 at 5:56 PM, Summers Pittman <supittma(a)redhat.com>
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>
> > 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
That's nice. But I was more asking if we would/should just offer these
guides for 3rd parties like FB/Google instead of having actual code,
meaning some convenience implementations for FB/Google like we do on
iOS/Windows.
>
>
>
>
> >
> >
> >>
> >>
> >> >
> >> >
> >> > _______________________________________________
> >> > 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
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
5:57 p.m.
Ahoy, let me give a more concrete example.
This is what I've been working since last week
http://cobblepot-abstractj.rhcloud.com/docs/guides/security/oauth2-guide/.
The credits to the team who worked hard into this documentation will be
added on the last section.
So for 3rd parties, we already had something build by the team. What I
did was just format and migrate to:
http://cobblepot-abstractj.rhcloud.com/docs/guides/security/oauth2-guide/...
What I have in mind per platform can be seen here:
- http://cobblepot-abstractj.rhcloud.com/docs/guides/security/oauth2-guide/...
- http://cobblepot-abstractj.rhcloud.com/docs/guides/security/oauth2-guide/...
Not sure if that answers your question, but if something is missing.
Feel free to add to AGSEC-200 with a full description. Also keep in mind
that I'm working on those sections.
On 2015-03-10, Matthias Wessendorf wrote:
On Tue, Mar 10, 2015 at 1:02 PM, Bruno Oliveira
<bruno(a)abstractj.org> wrote:
That's nice. But I was more asking if we would/should just offer these
guides for 3rd parties like FB/Google instead of having actual code,
meaning some convenience implementations for FB/Google like we do on
iOS/Windows.
--
abstractj
PGP: 0x84DC9914
1:30 a.m.
On Tue, Mar 10, 2015 at 11:57 PM, Bruno Oliveira <bruno(a)abstractj.org>
wrote:
Ahoy, let me give a more concrete example.
This is what I've been working since last week
http://cobblepot-abstractj.rhcloud.com/docs/guides/security/oauth2-guide/.
The guide is awesome, and I really like it
The credits to the team who worked hard into this documentation will
be
added on the last section.
IMO, if we add ack to one guide, let's do on other guides as well.
I think the motivation is here to reflect the amount of work, right?
And yes, writing guides is a lot of work. I wrote the UPS guids, and took
all the screenshots there (twice), and generated PDFs for product etc.
I know it's a lot of work, but IMO let's treat all guides the same: each
gets ack, or none.
So for 3rd parties, we already had something build by the team. What I
did was just format and migrate to:
http://cobblepot-abstractj.rhcloud.com/docs/guides/security/oauth2-guide/...
yeah, it's really cool
What I have in mind per platform can be seen here:
-
http://cobblepot-abstractj.rhcloud.com/docs/guides/security/oauth2-guide/...
-
http://cobblepot-abstractj.rhcloud.com/docs/guides/security/oauth2-guide/...
It's good, especially w/ the different 3rd party service specific code
Not sure if that answers your question, but if something is missing.
Feel free to add to AGSEC-200 with a full description. Also keep in mind
that I'm working on those sections.
No, I was more asking Summers, since he does not want something like
let keycloakConfig = KeycloakConfig(...)
in Android - I was wondering if he prefers to just have doc, instead of
convenience impl, like it exists for iOS/Windows
On 2015-03-10, Matthias Wessendorf wrote:
> On Tue, Mar 10, 2015 at 1:02 PM, Bruno Oliveira <bruno(a)abstractj.org>
wrote:
>
> That's nice. But I was more asking if we would/should just offer these
> guides for 3rd parties like FB/Google instead of having actual code,
> meaning some convenience implementations for FB/Google like we do on
> iOS/Windows.
>
--
abstractj
PGP: 0x84DC9914
_______________________________________________
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
7:28 a.m.
On 2015-03-11, Matthias Wessendorf wrote:
On Tue, Mar 10, 2015 at 11:57 PM, Bruno Oliveira
<bruno(a)abstractj.org>
wrote:
> Ahoy, let me give a more concrete example.
>
> This is what I've been working since last week
> http://cobblepot-abstractj.rhcloud.com/docs/guides/security/oauth2-guide/.
>
The guide is awesome, and I really like it
> The credits to the team who worked hard into this documentation will be
> added on the last section.
>
IMO, if we add ack to one guide, let's do on other guides as well.
I think the motivation is here to reflect the amount of work, right?
And yes, writing guides is a lot of work. I wrote the UPS guids, and took
all the screenshots there (twice), and generated PDFs for product etc.
I know it's a lot of work, but IMO let's treat all guides the same: each
gets ack, or none.
The goal is pretty much to give the props for people who wrote the
guide. But I think it's covered by the contributors section
anyways.
>
> So for 3rd parties, we already had something build by the team. What I
> did was just format and migrate to:
>
>
http://cobblepot-abstractj.rhcloud.com/docs/guides/security/oauth2-guide/...
yeah, it's really cool
>
>
> What I have in mind per platform can be seen here:
>
> -
>
http://cobblepot-abstractj.rhcloud.com/docs/guides/security/oauth2-guide/...
> -
> http://cobblepot-abstractj.rhcloud.com/docs/guides/security/oauth2-guide/...
It's good, especially w/ the different 3rd party service specific code
>
>
> Not sure if that answers your question, but if something is missing.
> Feel free to add to AGSEC-200 with a full description. Also keep in mind
> that I'm working on those sections.
>
No, I was more asking Summers, since he does not want something like
let keycloakConfig = KeycloakConfig(...)
in Android - I was wondering if he prefers to just have doc, instead of
convenience impl, like it exists for iOS/Windows
>
>
> On 2015-03-10, Matthias Wessendorf wrote:
> > On Tue, Mar 10, 2015 at 1:02 PM, Bruno Oliveira <bruno(a)abstractj.org>
> wrote:
> >
> > That's nice. But I was more asking if we would/should just offer these
> > guides for 3rd parties like FB/Google instead of having actual code,
> > meaning some convenience implementations for FB/Google like we do on
> > iOS/Windows.
> >
>
>
>
> --
>
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> 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
11:58 a.m.
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.
If we don't hard
code their configuration into the API then when they
change it we don't look bad. WIN-WIN
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.
Back to who is responsible for monitoring the changes from
these guys?
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
Fair enough.
We have demand from VK already so why not add that on in
right now?
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? Or
use a complicated and generic API, which may work, or not?
>
>
> _______________________________________________
> 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.
12:43 p.m.
As I already mentioned it, we can move those configurations into social
repo. Let me create a JIRA on iOS to decouple oauth2 vs social repo (social
being dependant on oauth2). Sth we discussed and agreed upon with abstractj
(I can't find the thread though, it might have being during security
meeting).
A nice entry point to demo OAuth2 is to use external providers as we did
for shoot demo app.
Another point i don't understand what so bad into renaming android-authz to
android-oauth2?
++
Corinne
On 9 March 2015 at 17:58, Summers Pittman <supittma(a)redhat.com> 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>
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.
If we don't hard code their configuration into the API then when they
change it we don't look bad. WIN-WIN
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.
Back to who is responsible for monitoring the changes from these guys?
>
> 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
Fair enough. We have demand from VK already so why not add that on in
right now?
> 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? Or
use a complicated and generic API, which may work, or not?
>
>
> >
> >
> > _______________________________________________
> > 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
1:13 p.m.
On 03/09/2015 01:43 PM, Corinne Krych wrote:
As I already mentioned it, we can move those configurations into
social repo. Let me create a JIRA on iOS to decouple oauth2 vs social
repo (social being dependant on oauth2).
Sth we discussed and agreed upon with abstractj (I can't find the
thread though, it might have being during security meeting).
A nice entry point to demo OAuth2 is to use external providers as we
did for shoot demo app.
Another point i don't understand what so bad into renaming
android-authz to android-oauth2?
Because this is an Authorization library not an
OAuth2 library. When we
have intent based APIs available we will be able to receive callbacks
from other installed apps on the device which won't be OAuth2.
Also because renaming the library is a huge PITA and will break semver.
We had this discussion ad nauseam during 2.0 development.
++
Corinne
On 9 March 2015 at 17:58, Summers Pittman <supittma(a)redhat.com
<mailto:supittma@redhat.com>> 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 <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.
If we don't hard code their configuration into the API then when
they change it we don't look bad. WIN-WIN
>
> 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.
Back to who is responsible for monitoring the changes from these guys?
>
>
> 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
Fair enough. We have demand from VK already so why not add that
on in right now?
> 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? Or use a complicated and generic API, which may work,
> or not?
>
>
>
> >
> >
> > _______________________________________________
> > 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 <tel:404%20941%204698>
> >>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 <mailto:aerogear-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Summers Pittman
>>Phone:404 941 4698 <tel:404%20941%204698>
>>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
_______________________________________________
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.
3:20 a.m.
On Mon, Mar 9, 2015 at 6:43 PM, Corinne Krych <corinnekrych(a)gmail.com>
wrote:
As I already mentioned it, we can move those configurations into
social
repo. Let me create a JIRA on iOS to decouple oauth2 vs social repo (social
being dependant on oauth2). Sth we discussed and agreed upon with abstractj
(I can't find the thread though, it might have being during security
meeting).
I recall that discussion, and since both sides here have valid arguments,
let's do that:
- authz (on Android) and -oauth2 on iOS/Windows/Cordova implement the raw,
API
-social: contains some of these convenient configurations, to make users
life easier
However I do NOT think that means we need to implement a ton of different
social adapters. It's more something for our users convenience and if users
want to contribute configurations for different services, that's the way to
go.
This means we can still focus on a clear/clean/raw OAuth2 impl., while
having configurations for some 3rd parties.
-Matthias
A nice entry point to demo OAuth2 is to use external providers as we
did
for shoot demo app.
Another point i don't understand what so bad into renaming android-authz
to android-oauth2?
++
Corinne
On 9 March 2015 at 17:58, Summers Pittman <supittma(a)redhat.com> 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>
> 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.
>
> If we don't hard code their configuration into the API then when they
> change it we don't look bad. WIN-WIN
>
>
> 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.
>
> Back to who is responsible for monitoring the changes from these guys?
>
>
>
>>
>> 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
>
> Fair enough. We have demand from VK already so why not add that on in
> right now?
>
>
>
>> 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? Or
> use a complicated and generic API, which may work, or not?
>
>
>>
>>
>> >
>> >
>> > _______________________________________________
>> > 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
>
_______________________________________________
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
3:40 a.m.
On 10 Mar 2015, at 09:20, Matthias Wessendorf
<matzew(a)apache.org> wrote:
On Mon, Mar 9, 2015 at 6:43 PM, Corinne Krych <corinnekrych(a)gmail.com> wrote:
As I already mentioned it, we can move those configurations into social repo. Let me
create a JIRA on iOS to decouple oauth2 vs social repo (social being dependant on oauth2).
Sth we discussed and agreed upon with abstractj (I can't find the thread though, it
might have being during security meeting).
I recall that discussion, and since both sides here have valid arguments, let's do
that:
- authz (on Android) and -oauth2 on iOS/Windows/Cordova implement the raw, API
-social: contains some of these convenient configurations, to make users life easier
#agreed
I have created:
https://issues.jboss.org/browse/AGIOS-409
to track it
However I do NOT think that means we need to implement a ton of different social
adapters. It's more something for our users convenience and if users want to
contribute configurations for different services, that's the way to go.
This means we can still focus on a clear/clean/raw OAuth2 impl., while having
configurations for some 3rd parties.
-Matthias
A nice entry point to demo OAuth2 is to use external providers as we did for shoot demo
app.
Another point i don't understand what so bad into renaming android-authz to
android-oauth2?
++
Corinne
On 9 March 2015 at 17:58, Summers Pittman <supittma(a)redhat.com> 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> 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.
If we don't hard code their configuration into the API then when they change it we
don't look bad. WIN-WIN
>
> 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.
Back to who is responsible for monitoring the changes from these guys?
>
>
> 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
Fair enough. We have demand from VK already so why not add that on in right now?
>
> 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? Or use a
complicated and generic API, which may work, or not?
>
>
>
> >
> >
> > _______________________________________________
> > 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 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
_______________________________________________
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
11:18 a.m.
On Mon, Mar 9, 2015 at 4:11 PM, Summers Pittman <supittma(a)redhat.com> wrote:
On 03/09/2015 11:06 AM, Erik Jan de Wit wrote:
Thoughts? Let me know if the idea is useless.
The thought of supporting vendor specific configuration details makes me
cringe.
It convenient and not likely to change
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.
I disagree. We offer free OS code for these services, and users are likely
using them, therefore it's nice to have these explicit config
Push is an exception ONLY because there isn't an equvalent open
solution
which has the same reach to devices.
I don't think that push is an exception due the lack of an OSS service,
which the same range. Even in the case there was something like that, we'd
still have same config for GCM/APNs, for a good reason
_______________________________________________
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
11:40 a.m.
On 03/09/2015 12:18 PM, Matthias Wessendorf wrote:
On Mon, Mar 9, 2015 at 4:11 PM, Summers Pittman <supittma(a)redhat.com
<mailto:supittma@redhat.com>> wrote:
On 03/09/2015 11:06 AM, Erik Jan de Wit wrote:
>>>
>>> Thoughts? Let me know if the idea is useless.
>> The thought of supporting vendor specific configuration details
>> makes me
>> cringe.
>
>
> It convenient and not likely to change
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.
I disagree. We offer free OS code for these services, and users are
likely using them, therefore it's nice to have these explicit config
Yes it is
nice to have.
Push is an exception ONLY because there isn't an equvalent open
solution which has the same reach to devices.
I don't think that push is an exception due the lack of an OSS
service, which the same range. Even in the case there was something
like that, we'd still have same config for GCM/APNs, for a good reason
You are
conflating the two arguments. If Push had a simple standard
configuration that didn't require propriety APIs and code then I would
make the same argument. Test their providers for compatibility, show
examples using those providers, and document how to do it. We would NOT
hard code their proprietary configuration into our libraries.
As it stands there is NO standard for Push that is available to 99% of
devices in the same way OAuth2 over HTTP is. The open source solutions
do not have the breadth that we need RIGHT NOW. So we link against and
include explicit in code support for proprietary services. Each Push
implementation is its own bespoke implementation that we hide behind
PushRegistrar interfaces.
>
> _______________________________________________
> 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.
11:15 a.m.
On Mon, Mar 9, 2015 at 4:06 PM, Erik Jan de Wit <edewit(a)redhat.com> wrote:
Thoughts? Let me know if the idea is useless.
The thought of supporting vendor specific configuration details makes me
cringe.
It convenient and not likely to change
yes, I agree it's convenient
_______________________________________________
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
10:35 a.m.
If that is not a good fit for Android, no problem.
On 2015-03-09, Summers Pittman wrote:
On 03/09/2015 09:42 AM, Bruno Oliveira wrote:
> Good morning, while writing our quickstarts, I found something that I
> would like to change.
>
> Currently to setup our OAuth2 providers we have to do something like
> this:
>
> AuthorizationManager.config(MODULE_NAME, OAuth2AuthorizationConfiguration.class)
> .setBaseURL(new URL("https://"))
> .setAuthzEndpoint(AUTHZ_ENDPOINT)
> .setAccessTokenEndpoint(AUTHZ_TOKEN_ENDPOINT)
> .setAccountId(AUTHZ_ACCOOUNT_ID)
> .setClientId(AUTHZ_CLIENT_ID)
> .setClientSecret(AUTHZ_CLIENT_SECRET)
> .setRedirectURL(AUTHZ_REDIRECT_URL)
> .setRefreshEndpoint(AUTHZ_TOKEN_ENDPOINT)
> .addAdditionalAccessParam(Pair.create("response_type",
"code"))
> .setScopes(Arrays.asList("photo_upload, publish_actions"))
> .asModule();
>
> Although, things like the url endpoint, access token endpoint, or the
> module will most of time remain unchanged. Unless you switch from Facebook to
> Keycloak for example. People don't care that much about these
> urls, but which provider they want to connect.
>
> So I would like to refactor the authz module from AGDroid, define the default
values
> for ommitted params and make the methods like setBaseURL for example,
> alternative. Something like this:
>
> AuthorizationManager.config(MODULE_NAME, OAuth2AuthorizationConfiguration.class)
> .setClientId(AUTHZ_CLIENT_ID)
> .setClientSecret(AUTHZ_CLIENT_SECRET)
> .asModule();
>
> Based on the module name, we instantiate the respective module with the
> default values already in.
>
> Thoughts? Let me know if the idea is useless.
The thought of supporting vendor specific configuration details makes me
cringe.
>
>
> --
>
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> 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
--
abstractj
PGP: 0x84DC9914
11:13 a.m.
+1 on this
On Mon, Mar 9, 2015 at 2:42 PM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
Good morning, while writing our quickstarts, I found something that
I
would like to change.
Currently to setup our OAuth2 providers we have to do something like
this:
AuthorizationManager.config(MODULE_NAME,
OAuth2AuthorizationConfiguration.class)
.setBaseURL(new URL("https://"))
.setAuthzEndpoint(AUTHZ_ENDPOINT)
.setAccessTokenEndpoint(AUTHZ_TOKEN_ENDPOINT)
.setAccountId(AUTHZ_ACCOOUNT_ID)
.setClientId(AUTHZ_CLIENT_ID)
.setClientSecret(AUTHZ_CLIENT_SECRET)
.setRedirectURL(AUTHZ_REDIRECT_URL)
.setRefreshEndpoint(AUTHZ_TOKEN_ENDPOINT)
.addAdditionalAccessParam(Pair.create("response_type",
"code"))
.setScopes(Arrays.asList("photo_upload, publish_actions"))
.asModule();
Although, things like the url endpoint, access token endpoint, or the
module will most of time remain unchanged. Unless you switch from Facebook
to
Keycloak for example. People don't care that much about these
urls, but which provider they want to connect.
So I would like to refactor the authz module from AGDroid, define the
default values
for ommitted params and make the methods like setBaseURL for example,
alternative. Something like this:
AuthorizationManager.config(MODULE_NAME,
OAuth2AuthorizationConfiguration.class)
.setClientId(AUTHZ_CLIENT_ID)
.setClientSecret(AUTHZ_CLIENT_SECRET)
.asModule();
Based on the module name, we instantiate the respective module with the
default values already in.
Thoughts? Let me know if the idea is useless.
--
abstractj
PGP: 0x84DC9914
_______________________________________________
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
3575
days inactive
3577
days old
33 comments
5 participants
participants (5)
-
Bruno Oliveira -
Corinne Krych -
Erik Jan de Wit -
Matthias Wessendorf -
Summers Pittman