[aerogear-dev] Proposal - Re: REST: auth: user registration endpoint

>So if a user wants to use our server-side bits, he always has to override for the registration - which is weird, IMO Yeah, that is true. And also we could simply provide examples in a user guide, so my point in the first post is not really valid. I'm changing my mind to +1 :) On 15 January 2013 07:15, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > but aren't two different defaults an odd API ? > > So if a user wants to use our server-side bits, he always has to override > for the registration - which is weird, IMO > > -M > > > On Tue, Jan 15, 2013 at 6:57 AM, Daniel Bevenius < > daniel.bevenius(a)gmail.com&gt; 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. >> >> >> On 15 January 2013 06:45, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >> >>> >>> >>> On Tue, Jan 15, 2013 at 6:09 AM, Daniel Bevenius < >>> daniel.bevenius(a)gmail.com&gt; 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&gt; wrote: >>>> >>>>> nice idea >>>>> >>>>> -1 to TODO changing >>>>> >>>>> On 14/01/2013, at 16:54, Summers Pittman <supittma(a)redhat.com&gt; 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&gt; 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 >> >> > > > -- > 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