February 26th, 2013 by JuanK

(by @JuanKRuiz )

El mercado de Apps es un mercado de oportunidades, es la democratización de la industria del software, y no es el futuro, una promesa, es una realidad del presente.

Cuando creamos un producto, queremos que este sea exitoso,  nos encontramos con un dilema acerca de las plataformas que queremos soportar versus el costo de producción que esto puede implicar.

Esto es un problema, debido a la forma en que cada plataforma construye sus aplicaciones a veces es inevitable terminar creando tres veces la misma aplicación.

Existen alternativas para solucionar este inconveniente, una de ellas es Phonegap la cual nos permiten crear fácilmente aplicaciones con javascript, css y HTML. Es una alternativa importante y conveniente en muchos escenarios, pero no en todos.

Cuando nuestra aplicación requiere un trabajo más elaborado a nivel de UI la aproximación de Phonegap nos empieza a quedar corta. Cada plataforma tiene características y funcionalidades muy puntuales que con un núcleo común y una interfaz gráfica unificada no logramos cubrir.

Otro aspecto a tener en cuenta es el tema de la segregación de responsabilidades, el despliegue de nuevas versiones y la escalabilidad de los servicios que consume nuestra aplicación, un backend creado de manera tradicional funciona, sin lugar a dudas, pero esta lejos de ser la mejor opción pues no es muy escalable y adicionalmente siempre tendrás que hacer desarrollo desde los diferentes clientes (las Apps) para consumir los servicios provistos por el backend.

Aquí es donde aparece la magia.

Mobile Services, backend en la nube

Lo primero que debemos comenzar a pensar es que en el mundo de la movilidad nuestra aplicación puede y debe utilizar servicios en la nube, es la forma más sencilla de tener un core de negocio único y escalable expuesto a través de interfaces desacopladas como lo son los servicios expuestos por REST, o cualquier otra forma similar de web services,

Si, la nube es una solución para buena parte del trabajo de backend, pero  aún seguimos desarrollando varios clientes para consumir dicho backend.

Aquí es donde la magia entra en juego y esa magia tiene nombre propio Windows Azure Mobile Services, una funcionalidad de Windows Azure que nos permite olvidarnos de la complejidad de la base de datos y de las características puntuales de cada plataforma de desarrollo para enfocarnos en nuestros datos y nada más.

Con Mobile Services puedes crear un backend en cuestión de minutos y permitir que este se extienda o modifique dinámicamente de acuerdo a como manipules tus objetos en la aplicación cliente, toda la funcionalidad esta expuesta haciendo uso de REST pero tu no debes programarlo, ni tampoco debes preocuparte por la conexión a la base de datos ni por construir las tablas.

Por si fuera poco (ya que de por si nos hace más de la mitad del trabajo). Mobile Services ya tiene un SDK para iOS (beta) , Android (beta) , Windows 8 y Windows Phone, qué quiere decir esto?

Quiere decir que ya tienes componentes hechos para consumirlo y que se programa prácticamente igual en cualquiera de las plataformas sin necesidad de repensar tú código, resultado: un solo backend, múltiples plataformas y en un abrir y cerrar de ojos.

C# en cualquier plataforma

Para crear la aplicación cliente requieres definir entidades, librerías, helpers y un sinfín de objetos necesarios para que el software funcione. En cada plataforma debes implementarlos siguiendo la sintaxis y gramática de cada lenguaje, accediendo a clases especificas de cada framework. Un trabajo interesante e incluso apasionante pero que definitivamente requiere de una inversión de tiempo considerable.

Que bueno sería tener la opción de escribir en el mismo lenguaje para las tres plataformas, y porque no poder acceder a varias de las librerías que el CLR nos ofrece.

Esto era una utopía, desarrollar para sistemas iOS, por ejemplo, implica no hacer uso de lenguajes interpretados,  que requieran algún tipo de middleware o runtime para que el sistema permita su ejecución, eso descarta inmediatamente lenguajes como Flash y tristemente lenguajes que se ejecuten sobre un JVM o sobre un CLR como el de .NET.

La industria esta llena de genios, algunos de ellos hacen historia. Miguel de Icaza un desarrollador Mexicano famoso por la creación del proyecto Gnome, el proyecto de Mono y un sinfín de herramientas más se dio cuenta del poder que el CLR y C# pueden dar a los desarrolladores de Apps para dispositivos móviles y ante la restricción de las plataformas decidió modificar el compilador de Mono para que no generara código intermedio (IL) sino que generara código nativo de una vez, el resultado dos productos que desde ya se posicionan como una opción poderosa para desarrollar Apps:

Xamarin.iOS (Monotouch)

Xamarin.Android (Monodroid)

Lo mejor de todo es que existe una versión gratuita que incluye como editor Mono Develop y a partir de la versión Bussiness son 100% compatibles y utilizables desde Visual Studio 2012.

Manos a la Obra

Estoy seguro que si tenias ideas acerca de como crear Apps multiplataforma con este artículo ya has visto la luz, Microsoft promueve y apoya 100% los sistemas interoperables, pues la realidad del mercado es que hay muchas opciones pera muchos gustos y necesidades.

Microsoft como creador de C# y del CLR promueve la adopción de estas tecnologías en diferentes plataformas y por medio de una plataforma en la nube de capacidades inimaginables como Windows Azure Te permite y allana el camino para tener el backend ideal sin importar las plataformas en que quieras implementar tu aplicación.

December 14th, 2012 by JuanK

Lo sé porque lo debo de saber, es mi propósito.

Hola Neo, te hace falta entender con que llave puedes entrar a la Matrix?

Neo: Tú

Llave: Authorization Header

Matrix: Azure Storage

Cada vez que vamos a enviar operaciones al storage de Windows Azure debemos llenar el header de autorización, esto en primera instancia parece una tarea fácil de realizar.

De acuerdo a la documentación el header se debe elaborar de la siguiente forma:

Authorization="[SharedKey|SharedKeyLite] <AccountName>:<Signature>"

Revisémoslo por partes.

[SharedKey|SharedKeyLite]

Un error muy común es presumir que SharedKey es la StorageKey que tenemos en nuestra cuenta de storage de Windows Azure, esta llave si tiene que ver en el proceso pero jamás se envía como parte del header.

En la historia de Azure Storage tenemos ya el release de unas cuantas versiones, y con cambios entre una y otra versión han llegado también cambios en la forma de obtener el signature. Es decir ha cambiado el esquema de autenticación.

En el caso de Blob y Queue Storage ahora se debe incluir información adicional al momento de calcular la firma, sin embargo por temas de compatibilidad hacia atrás se permite seguir calculando la firma de la forma como se hacia anteriormente de tal forma que no dejen de funcionar las cosas que ya venían haciéndolo.

Por ello cuando hacemos operaciones con versiones anteriores a 2009-09-19 hacemos uso de SharedKeyLite (llave compartida ligera) que no es sino una versión más sencilla, menos compleja de SharedKey.

En este artículo explicare como se hace utilizando SharedKey que al ser una versión más compleja ya incorpora en si misma los cálculos para de SharedKeyLite.

SharedKeyLite es el esquema usado para utilización de TableStorage aún en la versión 2012-02-12, es decir en el caso de Table Storage no se hace uso de SharedKey.

Así las cosas el encabezado queda de la siguiente manera.

Authorization="SharedKey <AccountName>:<Signature>"

AccountName

Es el nombre de la cuenta de storage de Windows Azure que se haya creado, por ejemplo MyStorage.

Authorization="SharedKey MyStorage:<Signature>"

Signature

Tricky part

La firma se utiliza para que tanto el cliente que envía la petición como el servidor de Azure Storage puedan validar que la información recibida es confiable y proviene de una fuente segura.

Así que con la información que existe en el el cliente que realiza la solicitud se realiza una serie de cálculos para obtener una firma, y en el servidor se realizan de nuevo dichos cálculos . Si la firma resultante es la misma entonces la operación es autorizada, de lo contrario es rechazada con un código de error  403 (forbidden).

La creación de la firma se puede reducir a dos pasos

1. Crear la cadena a firmar
2. Firmar la cadena

Crear la cadena a firmar

De acuerdo a la documentación la cadena a firmar es una cadena donde se concatenan una línea tras otra con

• La operación a realizar (PUT, GET, POST,DELETE, etc)
• Una serie de encabezados http pre establecidos, cuando no se tiene alguno de los encabezados se deja la línea en blanco
• Una serie de encabezados http canónicos, esto es los encabezados adicionados al request que comienzan por x-ms-, deben concatenarse y ordenarse de manera alfabética siguiendo este patrón "x-ms-headername:value\n", si algún header x-ms-no es utilizado simplemente no hace parte de la lista y no se deja salto de línea en su lugar.
• El nombre canónico del recurso, implica escribir el  recurso que se esta accediendo en formato "/accountName/containers/blobname\parameter:value\n" siendo la última parte una lista con los parámetros utilizados cada uno con formato "parámetro:valor\n" al final de esta cadena NO hay salto de línea.

Cuando no se tiene alguno de los encabezados del segundo punto se deja la línea en blanco.

Quedando de esta forma ( los comentarios están solo por claridad , NO hacen parte de la cadena )

GET\n /*HTTP Verb*/
\n    /*Content-Encoding*/
\n    /*Content-Language*/
\n    /*Content-Length*/
\n    /*Content-MD5*/
\n    /*Content-Type*/
\n    /*Date*/
\n    /*If-Modified-Since */
\n    /*If-Match*/
\n    /*If-None-Match*/
\n    /*If-Unmodified-Since*/
\n    /*Range*/
x-ms-date:Sun, 11 Oct 2009 21:49:13 GMT\n
x-ms-version:2009-09-19\n/*CanonicalizedHeaders*/
/myaccount/mycontainered\n
comp:metadata\n
restype:container\n
timeout:20/*CanonicalizedResource*/

Acá esta el extracto de los headers canónicos del ejemplo

x-ms-date:Sun, 11 Oct 2009 21:49:13 GMT\nx-ms-version:2009-09-19\n

Es decir cumplen con el formato "header:valor\n" y además están organizados alfabéticamente.

Este es un extracto del recurso canónico

/myaccount/mycontainered\ncomp:metadata\nrestype:container\ntimeout:20 

Nota: en el simulador de Azure Storage el nombre de la cuenta se debe colocar dos veces en el nombre de recurso canónico, ejemplo:

/<strong>myaccount/myaccount</strong>/mycontainered\ncomp:metadata\nrestype:container\ntimeout:20 

Si eliminamos los comentarios vemos como queda la cadena finalmente:

GET\n\n\n\n\n\n\n\n\n\n\n\nx-ms-date:Sun, 11 Oct 2009 21:49:13 GMT\nx-ms-version:2009-09-19\n/myaccount/myaccount/mycontainered\ncomp:metadata\nrestype:container\ntimeout:20

   Para tener más claridad respecto a como calcular los siguientes campos

• Que headers se deben utilizar
• Date / x-ms-date , que deben estar en formato RFC1123
• Canonicalized Headers, cuales se deben utilizar

les recomiendo revisar este enlace Put Blob (REST API)

Firmar la cadena

Ya teniendo preparada la cadena como lo vimos en el punto anterior se procede a firmarla.

De acuerdo a la documentación se debe hacer utilizando este patrón:

Signature=Base64(HMAC-SHA256(UTF8(StringToSign)))

Analizándolo de adentro hacia afuera:

(UTF8(StringToSign)

dado que la misma cadena a nivel binario puede ser completamente diferente lo primero que debemos hacer es convertirla a encoding UTF8. Una vez así ya sabemos que ambos lados firmarán la misma información.

HMAC-SHA256(UTF8(StringToSign))

Esto indica que la cadena debe firmarse utilizando el algoritmo HMAC-SHA256… solo que en la documentación se ha olvidado decir algo que es SUMAMENTE IMPORTANTE:

• Para firmar una cadena con dicho algoritmo se requiere una llave de encripción simétrica
• La llave de encripción simétrica es la CLAVE DE ACCESO PRIMARIA de la cuenta de Azure Storage que se esta utilizando.

Es importante tener en cuenta que la CLAVE DE ACCESO PRIMARIA es entregada por Windows Azure expuesta como una cadena Base64.

Hacer la tarea de firmado cambia de acuerdo al lenguaje y framework que estemos utilizando.

En este artículo muestro como hacerlo fácilmente desde Windows 8 (o sea WinRT), de paso haciendo la conversión al encoding UTF 8.

Cómo usar mecanismos de firma digital en Windows 8? – WinRT

Base64(HMAC-SHA256(UTF8(StringToSign)))

Los algoritmos de cifrado – hash – signature devuelven la información en forma de información binaria que no es representable por medio de cadenas de texto, y un header de un request http requiere que la información este en texto plano.

Una de las formas de mostrar contenido binario como texto plano es utilizando el esquema de codificación Base64 técnicamente no es una cosa que aprendas a hacer en un par de minutos, pero por fortuna es tan ampliamente adoptado que todos los frameworks ya lo incluyen como funcionalidad, de tal forma que envías un conjunto de datos y obtienes una cadena en dicho formato.

Así las cosas el header de autorización puede lucir de manera muy similar a esto:

Authorization="SharedKey MyStorage:Kcb0oMaIBCLITcBJStWjNj5WN309FEhbbfIb7ocX3bE="

Ejemplo

En este artículo, tengo un video donde se explica paso por paso como hacer una operación REST para manipular el storage de Windows Azure desde Windows 8 (WinRT)y de paso muestro como elaborar el header Authorization con todo lo expuesto en este artículo incluyendo como realizar la firma digital.

Video – Cómo acceder al Storage de Windows Azure Utilizando REST en Windows 8 – WinRT – C#