So I'm trying to figure out what we gain from this … now instead of putting your variantID in the JS, you are putting the variantID and a secret in the JS. I don't see any security gain here so trying to figure out what we gain.

On Jun 20, 2013, at 10:12 AM, Matthias Wessendorf <matzew@apache.org> wrote:

Hi,

with the use of this helper, it is "safe" (I think) to use the window.btoa function(see details), to perform a (simple) Base64 encoding.

Base64 encoding is required, since the "Device Registration" HTTP REST endpoint now uses HTTP_Basic (for details see the matching thread).

Currently we perform this code for "channel registration":

$.ajax({
  contentType: "application/json",
  dataType: "json",
  type: "POST",
  url: url,
  headers: {
    "ag-mobile-variant": variantID
  },
  data: JSON.stringify({
    category: messageType,
    deviceToken: endpoint.channelID,
    clientIdentifier: alias
  })
});

As mentioned on the "Security thread", the variantID is no longer a header, it is part of the HTTP_Basic auth process.

This is a (local) JavaScript change that I did. It works fine so far:

$.ajax({
  contentType: "application/json",
  dataType: "json",
  type: "POST",
  crossDomain: true,
  url: url,
  headers: {
    "Authorization": "Basic " + window.btoa(variantID + ":" + secret)
  },
  data: JSON.stringify({
    category: messageType,
    deviceToken: endpoint.channelID,
    alias: alias     ///// NOTE:: the key has changed..........
  })
});

The important thing: we add the "Authorization": "Basic " header and using the mentionedwindow.btoa() function for the actual encoding.

The same applies for the DELETE (unregistration).

Any thoughts? Otherwise, I'd send a PR.

Ah.... the dependency agains the Base64.js polyfill library would/should be included in our "grunt" build for "distribution", or would it be "just" declared (yeah, that's details but asking for curiousity)

--
Matthias Wessendorf

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

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev