[aerogear-dev] HTTP_Basic: SimplePush (Channel) Registration

Matthias Wessendorf matzew at apache.org
Thu Jun 20 11:49:25 EDT 2013


On Thu, Jun 20, 2013 at 5:46 PM, Kris Borchers <kris at redhat.com> wrote:

>
> On Jun 20, 2013, at 10:34 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>
>
>
> On Thu, Jun 20, 2013 at 5:32 PM, Kris Borchers <kris at redhat.com> wrote:
>
>>
>> On Jun 20, 2013, at 10:28 AM, Bruno Oliveira <bruno at abstractj.org> wrote:
>>
>> > Just one addition http://tools.ietf.org/html/rfc2617#section-4
>>
>> Right … even on the iOS and Android side of things, it is still very easy
>> to "decrypt" a base64 encoded string. Using HTTPS would help but that is
>> not foolproof either so we may want to think of some other method.
>>
>
>
> sure  - and nothing new here :)
> But better than nothing, for now
>
>
> Not sure I agree … seems like a waste if we know we won't use it in the
> future. Might as well have Bruno working on something real and get that in
> for August rather than just sitting on something that isn't right.
>

Ok,.. should I remove the security work I did ? wondering why there was no
feedback on the actual thread



>
>
>
>> >
>> > Bruno Oliveira wrote:
>> >> Don't feel safe because you're doing something with Base64 or using
>> >> basic authentication. It doesn't guarantee safety, the HTTP Basic
>> >> Authentication scheme is not considered a secure method without
>> TLS/SSL,
>> >> because username and password are passed over the network in cleartext.
>> >>
>> >> For this reason we will replace it with Digest or Hawk into the near
>> >> future.
>> >>
>> >> Matthias Wessendorf wrote:
>> >>> Hi,
>> >>>
>> >>> with the use of this helper
>> >>> <https://github.com/davidchambers/Base64.js>, it is "safe" (I think)
>> to
>> >>> use the |window.btoa| function(see details
>> >>> <https://developer.mozilla.org/en-US/docs/Web/API/window.btoa>), 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
>> >>> <http://lists.jboss.org/pipermail/aerogear-dev/2013-June/003233.html
>> >).
>> >>>
>> >>> 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 mentioned|window.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 at lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> >>
>> >
>> > --
>> > abstractj
>> >
>> > _______________________________________________
>> > aerogear-dev mailing list
>> > aerogear-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130620/952b30dc/attachment.html 


More information about the aerogear-dev mailing list