On Mon, Feb 17, 2014 at 4:37 PM, Bruno Oliveira <bruno@abstractj.org> wrote:


--
abstractj

On February 17, 2014 at 12:21:45 PM, Matthias Wessendorf (matzew@apache.org) wrote:
>
> On Wed, Feb 12, 2014 at 3:15 PM, Bruno Oliveira
> wrote:
> > ### Some considerations
> >
> > - The key pair will be generated in a separated project, not on
> UPS
> > - For the key store I'm considering to support the same data stores
> > provided by SPS. What Dan did is a nice a idea (
> > https://github.com/aerogear/aerogear-simplepush-server/tree/master/datastores
> > )
> >
>
> You mean the new "key server" supports multiple databases, right
> ?

Basically the possibility to store those key pairs in whatever storage mechanism you want: memory, Redis…

TBH not very critical atm.

yup
 

> > ## Changes suggested on UPS server
> >
> > 1. Login endpoint
> >
> > - Current login endpoint:
> >
> > POST /rest/auth/login
> >
> > - Suggested change:
> >
> > I'm not sure if we really need **POST** for login, unless
> > we are changing the state of some resource
> >
> > GET /rest/auth/login
> >
>
>
> Changing from POST to GET (for UPS login) is fine we me. The Login
> is
> really only relevant to the Admin UI.
> Historically: I picked POST because that's what all of our client
> libraries
> use as the default HTTP method for login (JS, iOS and Android)


That’s more a suggestion than a deal breaker. 

yeah, I am pretty flexible here :-) 
 

> > 2. Register push app
> >
> > - Our push clients will need to change to accept the public key
> > provided by the server and encrypt the passphrase. We can make
> use of *AG
> > Crypto* for it
> > - The basic workflow for our clients would be:
> >
>
>
> What clients do you mean? The only thing that really does a login
> against
> the server is the Admin UI (or a direct curl, using the same 'management'
> rest-endpoints which are accessed by the AdminUI).
>
>

By clients I mean: cURL, aerogear-unifiedpush-java-client, node version…etc. If I got it right, you must provide the master secret.

Right! for sending these 'sender clients' need to know the (umbrella) push applicationID and its masterSecret:
http://aerogear.org/docs/specs/aerogear-push-rest/Sender/
 
The suggestion is not only protect our passphrases,

the passphrase is really something specific to iOS
 
but also do not expose that masterSecret, because someone in possession of this could start to send push messages to the server. Am I wrong on it?

correct someone could to that. In the past we already at least chatted about having some sort of key/certificate for that + access-keys (e.g. per application).

-Matthias
 



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf