<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 17, 2014 at 4:37 PM, Bruno Oliveira <span dir="ltr"><<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
<br>
--<br>
abstractj<br>
<div class=""><br>
On February 17, 2014 at 12:21:45 PM, Matthias Wessendorf (<a href="mailto:matzew@apache.org">matzew@apache.org</a>) wrote:<br>
><br>
> On Wed, Feb 12, 2014 at 3:15 PM, Bruno Oliveira<br>
</div><div class="">> wrote:<br>
> > ### Some considerations<br>
> ><br>
> > - The key pair will be generated in a separated project, not on<br>
> UPS<br>
> > - For the key store I'm considering to support the same data stores<br>
> > provided by SPS. What Dan did is a nice a idea (<br>
> > <a href="https://github.com/aerogear/aerogear-simplepush-server/tree/master/datastores" target="_blank">https://github.com/aerogear/aerogear-simplepush-server/tree/master/datastores</a><br>
> > )<br>
> ><br>
><br>
> You mean the new "key server" supports multiple databases, right<br>
> ?<br>
<br>
</div>Basically the possibility to store those key pairs in whatever storage mechanism you want: memory, Redis…<br>
<br>
TBH not very critical atm.<br></blockquote><div><br></div><div>yup</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><br>
> > ## Changes suggested on UPS server<br>
> ><br>
> > 1. Login endpoint<br>
> ><br>
> > - Current login endpoint:<br>
> ><br>
> > POST /rest/auth/login<br>
> ><br>
> > - Suggested change:<br>
> ><br>
> > I'm not sure if we really need **POST** for login, unless<br>
> > we are changing the state of some resource<br>
> ><br>
> > GET /rest/auth/login<br>
> ><br>
><br>
><br>
> Changing from POST to GET (for UPS login) is fine we me. The Login<br>
> is<br>
> really only relevant to the Admin UI.<br>
> Historically: I picked POST because that's what all of our client<br>
> libraries<br>
> use as the default HTTP method for login (JS, iOS and Android)<br>
> <br>
<br>
</div>That’s more a suggestion than a deal breaker. <br></blockquote><div><br></div><div>yeah, I am pretty flexible here :-) </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><br>
> > 2. Register push app<br>
> ><br>
> > - Our push clients will need to change to accept the public key<br>
> > provided by the server and encrypt the passphrase. We can make<br>
> use of *AG<br>
> > Crypto* for it<br>
> > - The basic workflow for our clients would be:<br>
> ><br>
><br>
><br>
> What clients do you mean? The only thing that really does a login<br>
> against<br>
> the server is the Admin UI (or a direct curl, using the same 'management'<br>
> rest-endpoints which are accessed by the AdminUI).<br>
><br>
><br>
<br>
</div>By clients I mean: cURL, aerogear-unifiedpush-java-client, node version…etc. If I got it right, you must provide the master secret.</blockquote><div><br></div><div>Right! for sending these 'sender clients' need to know the (umbrella) push applicationID and its masterSecret:</div>
<div><a href="http://aerogear.org/docs/specs/aerogear-push-rest/Sender/">http://aerogear.org/docs/specs/aerogear-push-rest/Sender/</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
The suggestion is not only protect our passphrases,</blockquote><div><br></div><div>the passphrase is really something specific to iOS</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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?<br></blockquote><div><br></div><div>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).</div>
<div><br></div><div>-Matthias</div><div> </div></div><br><br clear="all"><div><br></div>-- <br>Matthias Wessendorf <br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</div></div>