> > > One thing that just came to mind is the implications for the clients.Yes!
> >
> > It shouldn't exist once we are server agnostic
> >
>
>
> you mean no implications on the client, right ?
> > >
> > > Now, I am wondering, what does the deprecation of the java libraries
> > > mean for the client offerings? For instance, once we did port
> >
> > I can be dead wrong, but this deprecation doesn't mean to much to me. Why?
> > AG Security is just few classes to fill in the gaps from PicketLink in the
> > past.
> >
> > Our offerings should not be tied to the server side, at least for
> > authentication.
>
>
> yeah - I am not sure that is really the case - I can be wrong; But I think
> that the "AGRestAuthentication.m" is a bit tied to AG Security's PicketLink
> Module
If that is happening, we must fix this.
>
> > How could I authenticate with AeroGear and Node.js?
> >
>
> I don't know. I *think* IF the endpoints would actually follow this spec,
> it would work:
> http://aerogear.org/docs/specs/aerogear-rest-api/#aerogear-security
Think about people interacting with legacies, they can’t just say “hey, would you mind to change your endpoint?”. For this reason,
we should have the flexibility to specify endpoints + parameters (https://github.com/aerogear/aerogear-android-cookbook/blob/master/src/org/jboss/aerogear/cookbook/authentication/HowToUseAuthentication.java#L70).
It shouldn't matter if the endpoint is “login” or “enroll”. Or parameters are “login” or “username”.
>
>
> But my hope is that, in the future, we only have OAuth2 and the 'legacy'
> bits like BASIC/DIGEST. Great thing here: they are actually (well) defined
> protocols.
That’s pretty much what we do today, I guess.
> > > the endpoints (for instance on AeroDoc) to vanilla PicketLink,
> > > should this iOS class/module just function like before? Or does
> >
> > Yes, they just need to be adapted and have AG Security removed. Today, we
> > don't need anymore 2 jars only for login/logout. Just stick with Apache
> > Shiro, PicketLink
>
>
> So, yeah if the endpoints ported to plain PL/Shiro/etc they would have to
> follow this spec, right ?
> http://aerogear.org/docs/specs/aerogear-rest-api/#aerogear-security
For examples, yes. But, we shouldn’t me tied to this. What would happen with the client if I want to name my endpoints with: “/register”, “/signin” and “/signout” ?
See: https://github.com/aerogear/aerogear-js/blob/master/tests/unit/authentication/authentication-rest.js#L13
> yeah - I picked iOS only because I know that code a bit better than Android
> or JS ;-)
I know, that new update for iOS 7.1 called “drain my battery” is awesome.