-M
On Tue, Jan 15, 2013 at 8:02 AM, Matthias Wessendorf <matzew(a)apache.org>wrote:
Kris,
the the "proposal thread"
-M
On Tue, Jan 15, 2013 at 7:00 AM, Kris Borchers <kris(a)redhat.com> wrote:
>
> On Jan 14, 2013, at 11:57 PM, Daniel Bevenius <daniel.bevenius(a)gmail.com>
> wrote:
>
> >is your -1 only for the TODO demo app, or also for the ag-security
> library?
> I think we could keep the server side in the both the TODO app and
> ag-security as is, and have overrides in the client examples which might be
> useful for users to see examples of.
>
>
> I can be convinced that the TODO app can be left as is and override with
> the clients. I don't agree with the library itself having a different
> default than the clients though. Seems like that would be more confusing
> than helpful for someone trying to use both.
>
>
>
> On 15 January 2013 06:45, Matthias Wessendorf <matzew(a)apache.org> wrote:
>
>>
>>
>> On Tue, Jan 15, 2013 at 6:09 AM, Daniel Bevenius <
>> daniel.bevenius(a)gmail.com> wrote:
>>
>>> -1 Let the client override this. I think it might be nice to show that
>>> this can be overriden and have an example to point users to.
>>>
>>
>>
>> is your -1 only for the TODO demo app, or also for the ag-security
>> library?
>>
>> -M
>>
>>
>>
>>>
>>> I've created
https://issues.jboss.org/browse/AEROGEAR-816 so that we
>>> can track this.
>>>
>>>
>>>
>>> On 14 January 2013 20:39, Douglas Campos <qmx(a)qmx.me> wrote:
>>>
>>>> nice idea
>>>>
>>>> -1 to TODO changing
>>>>
>>>> On 14/01/2013, at 16:54, Summers Pittman <supittma(a)redhat.com>
wrote:
>>>>
>>>> > +1 on having security be enroll.
>>>> >
>>>> > -1 on having TODO be enroll. This is because the TODO app should
>>>> > demonstrate that there is the ability to change things.
>>>> >
>>>> > On 01/14/2013 01:50 PM, Kris Borchers wrote:
>>>> >> +1
>>>> >>
>>>> >> On Jan 14, 2013, at 12:49 PM, Matthias Wessendorf <
>>>> matzew(a)apache.org> wrote:
>>>> >>
>>>> >>> Hi,
>>>> >>>
>>>> >>> our client libries are using the "auth/enroll"
value for the actual
>>>> >>> registration request, examples:
>>>> >>> -
>>>>
https://github.com/aerogear/aerogear-ios/blob/master/AeroGear-iOS/AeroGea...
>>>> >>> -
>>>>
https://github.com/aerogear/aerogear-js/blob/master/src/authentication/ad...
>>>> >>> -
>>>>
https://github.com/aerogear/aerogear-android/blob/master/src/org/jboss/ae...
>>>> >>>
>>>> >>> However, the server uses a different default
("auth/register"):
>>>> >>> -
>>>>
https://github.com/aerogear/aerogear-security/blob/master/src/main/java/o...
>>>> >>> -
>>>>
https://github.com/aerogear/TODO/blob/master/server/src/main/java/org/aer...
>>>> >>>
>>>> >>> It was a decision from the past, that we have this
"model",
>>>> however -
>>>> >>> rethinking causes some concerns... Is that really ideal?
Wouldn't
>>>> it
>>>> >>> be just
>>>> >>> better to have matching default, on the client AND the
server ?
>>>> >>>
>>>> >>> Please vote:
>>>> >>> [+1] let's change the server default to match the
"enroll" setting
>>>> >>> from the client libraries
>>>> >>> [0] I don't care
>>>> >>> [-1] nah, let's keep all as is, since the client can
override
>>>> everything
>>>> >>>
>>>> >>>
>>>> >>> Cheers!
>>>> >>> Matthias
>>>> >>>
>>>> >>> --
>>>> >>> 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
>>>> >>
>>>> >> _______________________________________________
>>>> >> 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
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
> _______________________________________________
> 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