Inyección de dependencias per-request en MVC4 y WebApi

¡Muy buenas! Si desarrollais una aplicación web con MVC4 o bien una API REST con WebApi y usáis, pongamos, EF para acceder a la BBDD ya sabréis (y si no, os lo cuento ahora :P) que lo ideal es que el tiempo de vida del DbContext sea el de toda la petición web (lo mismo aplica a ISession si usáis NHibernate, por supuesto).

En muchos ejemplos y blogs se lee código parecido al siguiente (p.ej. en un repositorio/dao):

public IEnumerable<MyEntity> GetAll()

{

    using (_context = new MyDbContext())

    {

        return _context.MyEntities.ToList();

    }

}

Este código, aunque funciona, no es del todo correcto: Cada llamada a uno de esos métodos crea y destruye un contexto de Entity Framework. Sin entrar en consideraciones de rendimiento, esto hace que si dentro de una misma acción de un controlador llamamos a dos métodos de este repositorio (o bien de repositorios distintos) se crearán dos contextos de EF con todo lo que ello conlleva.

Por supuesto, irnos al extremo contrario, y guardar el contexto en una variable estática y abrirlo en el Application_Start y cerrarlo en Application_End es una idea terrible… para empezar todos los usuarios estarían compartiendo el mismo contexto de base de datos y además DbContext no es thread-safe (tampoco ISession de NHibernate lo es, si ya corrías a descargartelo).

¿Y guardar el contexto en una variable de sesión? ¡Peor! Entonces tendrías un contexto abierto por cada usuario… idea terrible, pues si tu aplicación crece y tiene bastantes usuarios conectados a la vez, eso tumbaría tu base de datos. Además de que no hay nada que te garantice que todas las peticiones de un mismo usuario sean procesadas en un mismo thread.

¿La solución? Crear un contexto de BBDD por cada petición y cerrarlo una vez la petición se termina. De este modo, si dentro de la acción de un controlador llamas a 4 repositorios (por decir algo), esos 4 repositorios compartirán la instancia del contexto de bbdd. Al abrir y cerrar el contexto en cada petición podemos asegurar que no nos quedan contextos abiertos. A estos objetos que se crean y se destruyen una vez por cada petición, les decimos que tienen un tiempo de vida per-request.

Bien… veamos como podemos conseguir esto tanto en MVC4 como en WebApi, usando el contenedor IoC de Microsoft: Unity (en su versión 2.1).

Si no conoces nada acerca del funcionamiento de Unity, he escrito varios posts sobre él en este mismo blog.

A. Solución de MVC4

MVC4 viene bastante bien preparada para IoC, de hecho hay varias maneras en como se puede configurar la inyección de dependencias en MVC4. Debemos tener presente que Unity, a diferencia de otros contenedores IoC no es capaz de gestionar automáticamente objetos con un tiempo de vida per-request, así que nos lo tendremos que currar nosotros, aunque no es excesivamente dificil. Para “simular” el tiempo de vida per-request, nos vamos a aprovechar de la característica de “contenedor hijo” que tiene Unity. En Unity, a partir de un contenedor padre, podemos crear un contenedor hijo, que obtiene todos los mapeos de tipo del padre y puede añadir los suyos. Cuando se destruye este contenedor hijo, todos los mapeos nuevos que tenga dicho contenedor son destruídos, y se llama a Dispose() de todos los objetos singleton gestionados por este controlador hijo (que sean IDisposable).

A.1 Crear un contenedor hijo en cada inicio de petición y destruirlo al final

Ah… eso es fácil, ¿no? Nos basta usar Application_BeginRequest:

protected void Application_BeginRequest()

{

    var childContainer = _container.CreateChildContainer();

    HttpContext.Current.Items[_unityGuid] = childContainer;

}

Y Application_EndRequest, por supuesto:

protected void Application_EndRequest()

{

    var childContainer = HttpContext.Current.Items[_unityGuid] as IUnityContainer;

    if (childContainer != null)

    {

        childContainer.Dispose();

        HttpContext.Current.Items.Remove(_unityGuid);

    }

}

Por si te lo preguntas _container es el contendor de Unity principal y _unityGuid no es nada más que un objeto para usar como clave en HttpContext. Ambos se inicializan en Application_Start y son estáticos:

private static Guid _unityGuid;

private static IUnityContainer _container;

 

protected void Application_Start()

{

    _container = new UnityContainer();

    _unityGuid = Guid.NewGuid();

A.2 Mapear los tipos en el contenedor de Unity

Eso tampoco reviste especial complicación. La idea es:

  • Los singleton compartidos por todos los usuarios se declaran con el LifetimeManager ContainerControlledLifetimeManager en el contenedor principal
  • Los objetos de crear y destruir (p. ej. un repositorio o un controlador) se declaran con el LifetimeManager TransientLifetimeManager en el contenedor princial
  • Los objetos per-request (como el contexto de EF) se declaran con el LifetimeManager HierarchicalLifetimeManager en el controlador principal. Otra opción sería declararlos como singletons (ContainerControlledLifetimeManager) en el contenedor hijo.

Nota: El lifetime manager HierarchicalLifetimeManager es equivalente al ContainerControlledLifetimeManager (es decir existe una sola instancia en el contenedor) pero con la salvedad de que los contenedors hijos no comparten la instancia del contenedor padre, si no que cada contenedor hijo puede tener la suya propia.

Sería algo así como:

// Objetos «de usar y tirar»:

container.RegisterType<IMyRepo, MyRepository>();

// Contexto EF

container.RegisterType<MyDbContext>(new HierarchicalLifetimeManager());

A.3 Crear el “activador de controladores” (IControllerActivator)

Una vez configurado el contenedor debemos decirle a MVC4 que lo use. Una de las formas de hacerlo es crear un IControllerActivator. Esto nos basta para la mayoría de casos (cuando tan solo vamos a inyectar dependencias en los controladores, lo que es ásí casi siempre). ´

La idea es crear los controladores usando el controlador hijo que hemos guardado en HttpContext.Items:

public class UnityControllerActivator : IControllerActivator

{

 

    private Guid _containerGuid;

    public UnityControllerActivator(Guid containerGuid)

    {

        _containerGuid = containerGuid;

    }

    public IController Create(RequestContext requestContext, Type controllerType)

    {

        var container = requestContext.HttpContext.Items[_containerGuid] as IUnityContainer;

        if (container != null)

        {

            return container.Resolve(controllerType) as IController;

        }

        return null;

    }

}

Fijaos que simplemente llamamos a “Resolve” del contenedor que obtenemos de HttpContext.Items.

A.4 Configurar MVC4 para que use nuestro activador de controladores

Para que MVC4 use nuestro activador de controladores, debemos implementar un dependency resolver. A diferencia de la factoría de controladores p.ej, que se puede establecer a través de una clase estática), no hay ningún mecanismo para configurar que activador de controladores usará MVC. Si queremos usar uno específico (como es nuestro caso) debemos establecer un dependency resolver.

Para ello lo suyo es crearse uno que use el propio contenedor de Unity:

public class MvcConfig

{

    public static void Register(IUnityContainer container, Guid containerGuid)

    {

        container.RegisterInstance(typeof (IControllerActivator), new UnityControllerActivator(containerGuid));

        foreach (var type in

            Assembly.GetExecutingAssembly().GetExportedTypes().

                        Where(x => x.GetInterface(typeof(IController).Name) != null))

        {

            container.RegisterType(type);

        }

        DependencyResolver.SetResolver(

            t => container.IsRegistered(t) ? container.Resolve(t) : null,

            t => container.IsRegistered(t) ? container.ResolveAll(t) : Enumerable.Empty<object>());

    }

}

La llamada al método MvcConfig.Register iría en el Application_Start una vez creado el contenedor principal. Este método hace 3 cosas:

  1. Registra el activador de controladores como singleton en el contenedor.
  2. Registra todos los controladores que haya
  3. Finalmente crea el dependency resolver que usa el propio contenedor.

Con esto ya podemos inyectar las dependencias en nuestros controladores y en nuestros repositorios (a los controladores les inyectaríamos los repositorios y a los repositorios el contexto de EF).

B. Solución WebApi

Aunque, por oscuras razones, WebApi se distribuye junto a MVC y parece mucho lo mismo en el fondo hay muchas diferencias entre MVC y WebApi. Y una de esas diferencias es como funciona el tema de inyección de dependencias. Por lo tanto lo que hemos dicho de MVC no funciona para WebApi.

Si queremos obtener lo mismo (es decir que el contexto de EF tenga un tiempo de vida per-request) con WebApi, debemos seguir una estrategia distinta…

Lo que sí es igual es la configuración del contenedor (se siguen las mismas directrices que el punto A.2).

B.1 Crear un DependencyResolver de WebApi

Al igual que en MVC, necesitamos un dependency resolver, pero el de WebApi es distinto que el de MVC. Así si en MVC usábamos el método estático SetResolver de la clase DependencyResolver, en WebApi usaremos la propiedad DependencyResolver del objeto HttpConfiguration global, al que podemos acceder a través de GlobalConfiguration.Configuration.

A diferencia de MVC donde podemos pasar directamente dos delegates para crear el dependency resolver, en WebApi estamos obligados a crear una clase que implemente IDependencyResolver.

Además WebApi, a diferencia de MVC, ya viene “más o menos” preparado para el concepto de objetos per-request. Existe un método dentro de IDependencyResolver, llamado BeginScope. La idea es que cada vez que se necesite crear un “scope hijo” se llame a este método. Lo bonito sería que el framework lo hiciese por nosotros al crear un controlador, pero la realidad es que no lo hace. Nos tocará hacerlo nosotros.

Así para implementar IDependencyResolver vamos a usar dos clases:

public class UnityDependencyScope : IDependencyScope

{

    private IUnityContainer _container;

    protected IUnityContainer Container { get { return _container; } }

    public UnityDependencyScope(IUnityContainer container)

    {

        _container = container;

    }

    public void Dispose()

    {

        _container.Dispose();

    }

    public object GetService(Type serviceType)

    {

        return _container.IsRegistered(serviceType)

                    ? _container.Resolve(serviceType)

                    : null;

    }

    public IEnumerable<object> GetServices(Type serviceType)

    {

        return _container.ResolveAll(serviceType);

    }

}

Esta primera clase implementa IDependencyScope. Esta interfaz es la interfaz base de IDependencyResolver. De hecho IDependencyResolver añade tan solo el método BeginScope. La segunda clase es la que implementa IDependencyResolver:

public class UnityDependencyResolver : UnityDependencyScope, IDependencyResolver

{

    public UnityDependencyResolver(IUnityContainer container) : base (container)

    {

    }

    public IDependencyScope BeginScope()

    {

        return new UnityDependencyScope(Container.CreateChildContainer());

    }

}

Implementamos el método BeginScope retornando un contenedor hijo de nuestro contenedor. De esta manera ya podemos “encadenar” scopes hijos.

B.2 Crear el activador de controladores

Al igual que en MVC debemos crear un activador de controladores propio. Y por supuesto es distinto del de MVC 🙂

En este caso debemos implementar IHttpControllerActivator:

public class UnityHttpControllerActivator : IHttpControllerActivator

{

    private IUnityContainer _container;

    public UnityHttpControllerActivator(IUnityContainer container)

    {

        _container = container;

    }

    public IHttpController Create(HttpRequestMessage request, HttpControllerDescriptor controllerDescriptor, Type controllerType)

    {

        var scope = request.GetDependencyScope();

        return scope.GetService(controllerType) as IHttpController;

    }

}

La clave está en la llamada a GetDependencyScope del parámetro request. Esto creará un scope (llamando a BeginScope) por lo que el controlador que creemos se creará con el contenedor Unity hijo.

B.3 Configurar WebApi para que use nuestro activador de controladores

Eso si que es realmente sencillo. Simplemente registramos el activador de controladores y el dependency resolver en WebApi. Esto lo hacemos en el Application_Start, p.ej. en el propio método Register de la clase WebApiConfig que crea Visual Studio:

public static void Register(HttpConfiguration config, IUnityContainer container)

{

    config.DependencyResolver = new UnityDependencyResolver(container);

    container.RegisterInstance<IHttpControllerActivator>(new UnityHttpControllerActivator(container));

    foreach (var type in

        Assembly.GetExecutingAssembly().GetExportedTypes().

                    Where(x => x.GetInterface(typeof(IHttpController).Name) != null))

    {

        container.RegisterType(type);

    }

}

También debemos registrar todos los controladores de WebApi (de una forma análoga a la que usábamos al registrar los controladores MVC).

¿Y si tengo WebApi junto a MVC en un mismo proyecto?

Pues te tocará hacer todo lo de MVC y todo lo de WebApi. Lo único que no haces dos veces es la configuración del contenedor (punto A.2) ya que es la misma.

Eso sí, en este caso puedes hacer que si la petición HTTP es una llamada a WebApi, en lugar de una llamada a un controlador MVC, no se cree el contenedor hijo en Application_BeginRequest (ni se destruya en Application_EndRequest). Algo como:

protected void Application_BeginRequest()

{

    if (!Request.IsWebApiRequest())

    {

        // Código para MVC

    }

}

El método IsWebApiRequest es un método de extensión que me he inventado. La verdad, no tenía nada claro como diferenciar una petición de WebApi de una de MVC así que he cortado por lo sano:

public static class HttpRequestExtensions

{

    public static bool IsWebApiRequest(this HttpRequest @this)

    {

        return @this.FilePath.StartsWith(«/api/»);

    }

}

Exacto… Si la URL empieza por /api/ es que es una llamada a WebApi. Ya… cutre, pero oye tu: funciona 😛 Por supuesot, dependiendo de la tabla de rutas que tengas eso puede no ser cierto en tu caso 😉

Y nada más… con eso conseguimos un tiempo de vida per-request tanto en ASP.NET MVC4 como con WebApi 🙂

Saludos!

Knockback: Knockout y Backbone trabajando juntos

Este pasado sábado 26 de febrero, tuvimos el Four Sessions de Techdencias, en el que me lo pasé genial participando junto a Marc Rubiño en un duelo entre Knockout y Backbone para ver que librería era “mejor” para construir aplicaciones web. Al final la gente votó y la verdad és que ganó Marc por KO… 😛

Como digo estuvo divertido, aunque comparar Backbone con Knockout es como comparar peras con guisantes ya que, realmente, poco tenen que ver y además son muy complementarias. Backbone se centra más en dotarnos de herramientas para poder arquitecturar nuestra aplicación javascript. Mientras que Knockout tiene un sistema fenomenal de data-binding entre el DOM y el viewmodel pero nada más que eso (que no es poco): sigue siendo tarea nuestra organizar bien nuestra aplicación javascript y de ello Knockout se mantiene al margen.

La consecuencia de estos dos enfoques es que el código javascript que tiene que colocarse en Backone es siempre muy superior al de Knockout. No sólo eso, si no que Backbone por su propia concepción requiere unas habilidades de javascript superiores a las que requiere Knockout para empezar a hacer cosas. Una vez superados estos dos escollos, Backbone ofrece más facilidades que Knockout no sólo para organizar nuestro código de cliente, si no también para validaciones de modelos y creación de aplicaciones SPA.

Dos modelos distintos pero similares

Knockout apuesta por un modelo MVVM, muy semejante al que se encuentra en las tecnologías basadas en XAML: los enlaces se aplican declarativamente en el DOM y en javascript basta con crear un viewmodel que contenga los datos que son enlazados automáticamente (y de forma bidireccional). Knockout ofrece soporte para varios tipos de bindings y la capacidad de definirnos nuestros propios para tareas más avanzadas.

El siguiente código muestra un textbox y una label que se va modificando a medida que vas modificando el contenido del textbox:

<!DOCTYPE html>

<html>

    <head>

        <script src="http://knockoutjs.com/downloads/knockout-2.2.1.js"></script>

    </head>

    <body>

        <input type="text" data-bind="value: name, valueUpdate: ‘afterkeydown’" />

        <br />

        <label data-bind="text: greeting" />

    </body>

 

    <script>

        (function () {

            var MyViewModel = function (aName) {

                var self = this;

                self.name = ko.observable(aName);

                self.greeting = ko.computed(function () {

                    return "Hola " + self.name();

                });

            }

            var vm = new code("eiximenis");

            ko.applyBindings(vm);

        })();

    </script>

</html>

Podemos ver el uso del atributo data-bind para declarar los enlaces declarativamente y el código javascript que se limit a crear el viewmodel con las dos propiedades usadas (name y greeting).

Backbone por su parte apuesta por un modelo más parecido a MVC, con sus modelos y sus vistas claramente diferenciados. Para crear la misma aplicación con Backbone se requiere bastante más código:

<!DOCTYPE html>

<html>

    <head>

        <script src="http://code.jquery.com/jquery.min.js"></script>

        <script src="http://underscorejs.org/underscore-min.js"></script>

        <script src="http://backbonejs.org/backbone-min.js"></script>

        <script type="text/template" id="viewTemplate">

            <input type="text" value="<%- name %>" />

            <br />

            <label><%- greeting %></label>

        </script>

    </head>

    <body>

    </body>

    <script>

        (function () {

            var MyModel = Backbone.Model.extend({

                defaults: { name: ‘eiximenis’ },

            });

            var MyView = Backbone.View.extend({

                initialize: function () {

                    var self = this;

                    this.model.on(‘change:name’, function () {

                        self.updateLabel();

                    });

                },

                events: { ‘keyup input’: ‘changeName’ },

                changeName: function (evt) {

                    this.model.set(‘name’, $(evt.target).val());

                },

                updateLabel: function () {

                    this.$("label").text(this.greeting());

                },

                greeting: function () {

                    return "Hola " + this.model.get(‘name’);

                },

                render: function () {

                    this.$el.empty();

                    var data = { name: this.model.get(‘name’), greeting: this.greeting() };

                    this.$el.html(_.template($("#viewTemplate").html(), data));

                    return this;

                }

            });

            $(function () {

                var model = new MyModel();

                var view = new MyView({ model: model, el: ‘body’ });

                view.render();

            });

        })();

    </script>

</html>

Aunque pueda parecer que están a las antípodas, en el fondo los modelos de Knockout y Backbone son similares: ambos tienen una clase javascript que se encarga de mantener los datos y ambos tienen una vista que se encarga de representarlos. La diferencia fundamental es que en Knockout la vista es el propio DOM que contiene los atributos data-bind y en Backbone la vista debe crearse y debe tener todo el código necesario para gestionar la comunicación entre el DOM (DOM que crea la propia vista) y el modelo de datos.

¿Y pueden trabajar juntos?

La verdad es que para pequeñas aplicaciones no tiene sentido usar Backbone, y probablemente con Knockout tirarás perfectamente. Pero, si nos ponemos en la situación de que queremos usar Backbone… no podríamos aprovecharnos del sistema de enlaces de Knockout y ahorrarnos toda esa parte?

Pues sí, y la respuesta se llama Knockback.

Usando Knockback nuestro código quedaría más o menos como:

<!DOCTYPE html>

<html>

    <head>

        <script src="http://code.jquery.com/jquery.min.js"></script>

        <script src="http://underscorejs.org/underscore-min.js"></script>

        <script src="http://backbonejs.org/backbone-min.js"></script>

        <script src="http://knockoutjs.com/downloads/knockout-2.2.1.js"></script>

        <script src="https://raw.github.com/kmalakoff/knockback/0.16.8/knockback.min.js"> </script>

    </head>

    <body>

        <input type="text" data-bind="value: name, valueUpdate:’afterkeydown’" />

        <br />

        <label data-bind="text: greeting"></label>

        <input type="button" id="ju" value="!!" />

    </body>

    <script>

        (function () {

            var MyModel = Backbone.Model.extend({

                defaults: { name: ‘eiximenis’ },

            });

            $(function () {

                var model = new MyModel();

                var ViewModel = function (model) {

                    var self = this;

                    this.name = kb.observable(model, ‘name’);

                    this.greeting = ko.computed(function () {

                        return "Hello " + self.name();

                    })

                }

                ko.applyBindings(vm);

            });

        })();

    </script>

</html>

En el fondo volvemos a un esquema muy parecido al código con knockout, la única diferencia principal es que ahora tenemos un modelo de Backbone y un viewmodel de Knockout. Lo que ya no tenemos (puesto que nos lo proporciona Knockout) es la vista de Backbone.

Evidentemente, si en este ejemplo no tiene mucho sentido aplicar Backbone, tampoco lo tendrá aplicar Knockback, pero vamos a hacer un ejercicio de imaginación y situarnos en un proyecto mucho más complejo.

En este caso, al usar Knockback obtenemos la sencillez de Knockout para los enlaces y además la potencia de Backbone para los modelos. En nuestro ejemplo ViewModel y modelo eran casi idénticos, pero en un ejemplo más grande el ViewModel puede diferir bastante del modelo: Este contiene los datos tal y como van a ser enviados y recibidos desde el servidor y lo gestiona Backbone. Así nos podemos aprovechar de la persistencia automática de Backbone, el enrutamiento en cliente, la ordenación y filtrado de colecciones automática y todo lo que Backbone nos ofrece en los modelos. Por otra parte el Viewmodel contendría los datos preparados para ser enlazados directamente con el DOM.

Imagina una aplicación que muestre los datos generales de una póliza, y luego tenga varias pestañas con información addicional. Pues bien, toda la información puede estar en un modelo de Backbone, que contendrá todos los datos de la póliza, mientras que tendríamos varios viewmodels de Knockout, uno por cada pestaña, que son los que usaríamos para enlazar con el DOM.

Lo que Knockback nos ofrece es que los viewmodels y los modelos estén sincronizados entre ellos (si modifico algo en el viewmodel el modelo se entera de dicha modifcación).

A modo de resumen podríamos decir que un Modelo de Backbone:

  • Es independiente del DOM
  • Ligado fuertemente a los datos que vienen del servidor
  • Representa datos complejos, muchos de los cuales pueden no visualizarse
  • Se modifica a través de la lógica de negocio

Mientras que un ViewModel de Knockout:

  • Está atado a la vista, en el sentido que contiene aquellas propiedades que la vista quiere mostrar
  • No está atado a los datos del servidor, de hecho probablemente tenga tan solo un subconjunto de dichos datos
  • Aplicaciones complejas tenderán a tener varios viewmodels de knockout por cada modelo de Backbone

Por supuesto lo más importante es usar cada librería para lo que ha sido pensada y tener siempre bien claro que ventajas e inconvenientes nos puede tener usar cada una de ellas 🙂

Un saludo!

pd: Ah sí… y eso de las librerías de javascript está en constante evolución! No todo es Backbone o Knockout! Existen más por ahí afuera y en breve espero poder hablaros de alguna de ellas! 😉

¿Están tus servicios REST en otro servidor?

Muy buenas, en este post vamos a hablar de lo que ocurre si los servicios REST de tu aplicación están en otro servidor distinto al de tu aplicación web… Terminaremos hablando de CORS, pero antes lo haremos de JSONP y empezaremos por el…

… Orígen

No, no me refiero a la onírica película con Di Caprio, aunque muchas veces el desarrollo web se parezca a una pesadilla, si no a lo que en el mundo web entendemos como el origen de una web.

Es un concepto muy sencillo pero que debemos tener siempre presente: protocolo, host y número de puerto conforman un orígen. Así las urls

¿Es simple no? Bueno pues ahora la regla de oro: Los navegadores tienen prohibido procesar una llamada Ajax (con XmlHttpRequest) desde una página que esté en un orígen hacia una URL que sea de otro origen.

Punto.

Vale, que nos impidan hacer peticiones ajax a otro dominio es una muy buena medida de seguridad, pero a veces es una necesidad legítima: Imagina que tienes la API REST de tu aplicación publicada en http://api.foo.com y tu aplicación web en http://foo.com. Pues si desde tu web quieres hacer una petición ajax a alguno de tus servicios: mala suerte.

Para hacer algunas demos voy a crear una solución de vs2012 con dos proyectos web:

image

Uno será mi aplicación web y el otro será mi API. El proyecto WebApi (que yo he llamado CORSDemo) tan solo tiene un controlador, que responde a las peticiones de tipo /Beer/id:

public class BeersController : ApiController

{

    public Beer Get(int id)

    {

        return new Beer {Name = "Cerveza " + id, Id = id};

    }

}

Por otro lado la aplicación web (que he llamado CORSDemo.Web) tiene un solo controlador (Home) que devuelve una vista. Dicha vista intenta hacer una llamada Ajax al servicio REST:

<h2>Index</h2>

 

@section scripts

{

    <script>

    (function() {

            var xhr = new XMLHttpRequest();

            console.log(‘Invocando servicio REST’);

            xhr.open(‘GET’, ‘http://localhost:2614/Beers/10’, true);

            xhr.setRequestHeader("Accept", "application/json");

            xhr.addEventListener(‘readystatechange’, function (e) {

                console.log(‘readyState: ‘ + xhr.readyState)

                console.log(‘status: ‘ + xhr.status);

                console.log(‘response: ‘ + xhr.responseText);

            });

            xhr.send();

    })();

    </script>

}

Si pongo en marcha el proyecto, efectivamente en mi IIS Express tengo dos aplicaciones web:

image

En mi caso la aplicación WebApi está en localhost:2614 y la aplicación web está en localhost:2628. Y si navego a localhost:2628 veo lo que ya me esperaba:

image

El navegador me muestra el error que no puede realizar la llamada ya que el servicio REST está en otro orígen.

Rompiendo la barrera – jsonp

Por suerte (y por desgracia también, todo tiene las dos caras de la moneda), hay muchas cabezas pensantes por ahí y algunas de ellas se dedicaron a ver si existía alguna posible manera de saltarse esta medida de seguridad. Y dieron con una. Ciertamente no abrieron un boquete en la muralla de seguridad, pero sí una brecha y durante vario tiempo nos hemos estado aprovechando de ella. Esta brecha es la técnica conocida como jsonp. Veamos muy brevemente en que consiste…

El objetivo final es conseguir llamar al servicio REST que tenemos y recuperar los datos. Eso debemos hacerlo de forma asíncrona al igual que hace XMLHttpRequest, que ya hemos visto que no podemos usar.

La técnica de jsonp es muy simple, pero requiere eso sí que los servicios REST devuelvan json (no sirve si devuelven algún otro tipo de datos como XML).

Consiste básicamente en sustuir la llamada AJAX por un tag <script>. El tag <script> permite sin ningún problema incluir scripts de otros orígenes (si no, no podríamos usar CDNs p. ej.). Asi en nuestro caso vamos a añadir un tag <script> como el siguiente:

<script src="http://localhost:2614/Beers/10"></script>

Ahora el navegador realiza la llamada web y obtiene el JSON pero… por supuesto ahora tenemos un error de javascript:

image

Eso es debido a que el navegador está intentando interpretar el JSON como si fuese código javascript y por supuesto {"Name":"Cerveza 10","Id":10} no es un código javascript válido. No lo es, pero le falta muy, muy poco para serlo.

Ahora toca que el servicio REST colabore un poco. Que nos devuelva los datos directamente en JSON no nos sirve ya que hemos visto que el navegador no puede interpretarlos. Pero… y si en lugar de devolvernos los datos en JSON el servicio REST nos devuelve algo como:

func_callback({"Name":"Cerveza 10","Id":10});

Ah! Esto sí que es javascript válido. A este código lo llamamos el código jsonp.

Tan solo falta que func_callback esté definida y de eso ya se encargaría la aplicación web.

Veamos como modificar el servicio en WebApi para soportar jsonp. Para ello nos basaremos en la querystring.

Soportando JSONP en WebApi

Que yo sepa WebApi NO tiene soporte directo para jsonp. Por suerte añadirlo es trivial. Basta con usar un MediaTypeFormatter nuevo:

public class JsonpMediaFormatter : JsonMediaTypeFormatter

{

    public JsonpMediaFormatter()

        : base()

    {

        SupportedMediaTypes.Add(DefaultMediaType);

        SupportedMediaTypes.Add(new MediaTypeHeaderValue("text/javascript"));

        MediaTypeMappings.Add(new QueryStringMapping("jsonp", "true",DefaultMediaType));

    }

 

 

    public override Task WriteToStreamAsync(Type type, object value, Stream writeStream, System.Net.Http.HttpContent content, TransportContext transportContext)

    {

        var callback = GetJsonpCallback();

        if (string.IsNullOrEmpty(callback))

            return base.WriteToStreamAsync(type, value, writeStream, content, transportContext);

 

        Encoding encoding = SelectCharacterEncoding(content.Headers);

        return Task.Factory.StartNew(() =>

            {

                var bytes = encoding.GetBytes(string.Format("{0}(", callback));

                writeStream.Write(bytes, 0, bytes.Length);

            }).

            ContinueWith(task =>

                {

                    base.WriteToStreamAsync(type, value, writeStream, content, transportContext);

                }).

                ContinueWith(task =>

                    {

                        var bytes = encoding.GetBytes(");");

                        writeStream.Write(bytes, 0, bytes.Length);

                    });

    }

 

    protected string GetJsonpCallback()

    {

        if (HttpContext.Current.Request.HttpMethod != "GET") return null;

        if (HttpContext.Current.Request.QueryString["jsonp"] != "true") return null;

        return HttpContext.Current.Request.QueryString["callback"] ?? "func_callback";

    }

}

Para registrar este MediaTypeFormatter debemos añadir la siguiente línea en el Application_Start:

GlobalConfiguration.Configuration.Formatters.Add(new JsonpMediaFormatter());

Ahora nuestro JsonpMediaFormatter actuará si la petición tiene un parámetro querystring llamado jsonp y cuyo valor sea true. Además admite otro parámetro llamado callback con el valor de la función callback. Por lo tanto modificamos ahora el tag <script> para que pase esos dos parámetros y también definimos antes la función show_beer:

<script>

    function show_beer(data) {

        alert(data.Name);

    }

</script>

 

<script src="http://localhost:2614/Beers/10?jsonp=true&callback=show_beer"></script>

¡Y ya hemos terminado! Si ahora ejecutamos la página vemos que efectivamente nos hemos saltado la restricción de orígen:

image

¿Por qué digo que JSONP es una brecha en lugar de un agujero en la seguridad? Muy simple… porque está basado en el tag <script> lo que implica que tan solo funciona para el verbo http GET.

Así, aunque JSONP es un parche que nos puede sacar de muchos apuros, era evidente que necesitábamos una manera segura de poder llamar a servicios REST que estuviesen en otro dominio… y la W3C se puso manos a la obra y definió CORS.

CORS

Las ventajas de CORS sobre JSONP son enormes: CORS funciona para todos los verbos HTTP, permite usar XMLHttpRequest así que no tenemos que andar con trapicheos como en JSONP y además es un estándard y no una técnica salida de una mente calenturienta.

Por supuesto tiene sus inconvenientes: tiene que estar soportado por el servidor y por el navegador. Si os vais a http://caniuse.com/#search=CORS podeis ver como p.ej. IE NO SOPORTA CORS hasta la versión 10 (En la versión 8 y 9 soporta un pseudo-CORS a través del objeto XDomainRequest). Es la historia de siempre… 🙁

CORS se basa en las cabeceras HTTP. Básicamente la idea es que el navegador envía una petición con la cabecera http “Origin” que contiene el origen de la aplicación web. El servidor recibe esta petición y si admite dicho orígen devuelve en la respuesta la cabecera “Access-Control-Allow-Origin” con el nombre de los orígenes admitidos.

Volvamos de nuevo al código original que teníamos antes de ver jsonp. Si abro una ventana de Chrome y navego a la aplicación web, donde se hace la llamada con XMLHttpRequest y miro las cabeceras enviadas:

image

Fijaos como el navegador envía la cabecera “Origin”. Por lo tanto Chrome ya está intentando iniciar una negociación CORS, pero como el servidor no le responde con la cabecera Access-Control-Allow-Origin Chrome no procesa la petición y no podemos acceder a la respuesta.

En este punto voy a dejar una cosa bien clara: La petición es enviada por el navegador y por lo tanto es RECIBIDA por el servidor. Lo podéis comprobar poniendo un Breakpoint en el controlador de WebApi y veréis que se llega a él. Pero la respuesta NO ES PROCESADA por el navegador. Otra forma de verlo es usando fiddler:

image

Como podemos ver hay una petición (con su cabecera Origin) y una respuesta. Solo que el navegador nos ignora la respuesta debido a que no hay la cabecera CORS Access-Control-Allow-Origin.

Soporte para CORS en WebApi

De nuevo, que yo sepa, no hay soporte out-of-the-box en WebApi para CORS, aunque por suerte añadir uno básico es trivial. Si para JSONP usábamos un MediaTypeFormatter, para CORS usaremos un Message Handler para conseguirlo:

Nota: El Message Handler aquí mostrado implementa una parte muy pequeña de CORS. Está pensado a modo de información y no para poner en producción. Solo por citar una de sus limitaciones no está preparado para lidiar con las peticiones “preflight” de CORS que se dan en según que escenarios y que no tratamos en este post.

public class CorsMessageHandler : DelegatingHandler

{

    protected async override System.Threading.Tasks.Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, System.Threading.CancellationToken cancellationToken)

    {

        if (request.Headers.Contains("Origin"))

        {

            var response = await base.SendAsync(request, cancellationToken);   

            response.Headers.Add("Access-Control-Allow-Origin",

                                    request.Headers.GetValues("Origin"));

            return response;

        }

        return await base.SendAsync(request, cancellationToken);

    }

}

Este MessageHandler es muy sencillo: si la petición contiene la cabecera “Origin” añade la cabecera “Access-Control-Allow-Origin” con el mismo valor que la cabecera Origin.

Tenemos que registrar este Message Handler, en el Application_Start:

GlobalConfiguration.Configuration.MessageHandlers.Add(new CorsMessageHandler());

¡Listos! Hemos terminado. Si ahora navegamos de nuevo a la aplicación web vemos que la llamada Ajax se efectúa sin problemas:

image

Y si miramos en la pestaña network veremos la cabecera Access-Control-Allow-Origin que ahora envía el servidor como respuesta:

image

Para más información, aquí tenéis la especificación de CORS del W3C.

Si buscáis un soporte de CORS realmente completo para WebAPi echad un vistazo a este post de brocakllen: http://brockallen.com/2012/06/28/cors-support-in-webapi-mvc-and-iis-with-thinktecture-identitymodel/

Saludos!

jQuery 1.9 y el “unobtrusive ajax” de ASP.NET MVC

Hace justo casi nada que ha salido la nueva versión de jQuery 1.9 y he aprovechado para actualizar una aplicación web que tenía a medias.

Pues bien, si actualizas una aplicación ASP.NET MVC que use unobtrusive ajax y actualizas a ASP.NET MVC… deja de funcionar. Pero vayamos por partes…

Reproducción del problema

Abre VS2012 y crea un nuevo proyecto ASP.NET MVC4. Usa la plantilla Basic (no la Empty). Podemos ver como por defecto nos ha agregado, entre otros, el fichero jQuery-unobstrusive-ajax. Este fichero es el que da soporte para el unobtrusive ajax de MVC. Ya hablé en este blog hace un tiempecillo sobre el unobstrusive ajax de MVC.

Para ver el problema en acción, añadimos un controlador HomeController con la acción Index por defecto y una acción que he llamado PostData:

public class HomeController : Controller

{

    public ActionResult Index()

    {

        return View();

    }

    [HttpPost]

    public ActionResult PostData(string name)

    {

        ViewBag.DataName = name;

        return PartialView();

    }

}

La vista Index.cshtml es muy sencilla, tiene tan solo un Ajax.BeginForm:

@using (Ajax.BeginForm("PostData", new AjaxOptions() {HttpMethod = "Post", UpdateTargetId = "datadiv"}))

{

 

    <label for="name">Name: </label>

    <input type="text" name="name" id="name"/>

    <input type="submit" value="Send" />

}

<hr />

Aquí irá el resultado: <p />

<div id="datadiv">

</div>

Y finalmente nos queda la vista PostData.cshtml que contiene el código HTML que se incrustará en el div “datadiv”:

<h2>Hola @ViewBag.DataName</h2>

Tnemos que hacer una última modificación a la página de _Layout.cshtml que es añadir el bundle que nos añade (entre otros) jQuery-unobstrusive-ajax.js. Para ello añadimos la siguiente línea justo antes del RenderSection:

@Scripts.Render("~/bundles/jqueryval")

Listos, con esto tenemos un formulario que es enviado via Ajax al servidor y el resultado (la vista PostData.cshtml) se incrusta en el formulario.

Ahora simplemente reemplazamos el fichero de jQuery 1.7.1 por el de jQuery 1.9.0 y volvemos a probar la aplicación.

Veréis que el formulario no se envía por Ajax (en su lugar se envía por un POST normal) por lo que el resultado de PostData.cshtml no se incrusta en el div si no que pasa a ser toda la nueva página.

La causa del error y la solución

La causa es que jquery-unobtrusive-ajax.js que es quien se encarga de dar soporte al unobtrusive ajax de ASP.NET MVC usa el método live de jQuery. Pero dicho método fue declarado obsoleto en jQuery 1.7 y se ha eliminado en 1.9. Dicho método permitía asociarse a un evento de cualquier elemento del DOM actual o futuro.

El método que debe usarse actualmente en lugar de live es el método on. No obstante la sintaxis es un poco distinta, ya que el método on tiene más usos en jQuery.

$("form[data-ajax=true]").live("submit", function (evt) {

Vamos a modificar la llamada a “live” a una llamada a “on”. Para que “on” actue como live debemos pasarle a “on” 3 parámetros:

  • El evento (igual que live, será “submit”)
  • Un selector (elementos “hijos”) del selector base que es el que debe existir siempre
  • La función gestora (igual que live).

En este caso nuestra línea queda como:

 $("body").on("submit", "form[data-ajax=true]",function (evt) {

Fijaos: he movido el selector al segundo parámetro de “on” y he puesto como selector base “body” (no es el más óptimo, pero así estoy seguro de que existe siempre). La idea es que la función pasada se asocia a todos los elementos presentes y futuros de tipo “form[data-ajax=true]” que estén dentro del selector base (body).

Para el resto de llamadas a live (hay 3 más) hacemos la misma sustitución que nos quedarán así:

$("body").on("click", "form[data-ajax=true] :submit", function (evt) {

$("body").on("click", "a[data-ajax=true]", function (evt) {

$("body").on("click", "form[data-ajax=true] input[type=image]", function (evt) {

Y listos! Con esto ya hemos recuperado la funcionalidad del unobtrusive ajax de MVC y nuestra aplicación debería volver a funcionar correctamente!

Saludos!

PD: Actualmente el fichero jquery-unobstrusive-ajax.js se distribuye a través de un paquete de NuGet llamado Microsoft jQuery Unobtrusive Ajax. Es de esperar que en breve lo actualizarán 😉

ASP.NET WebApi – Establecer una cookie desde un ApiController

Hoy, para una prueba de concepto que estoy realizando, me he encontrado con la necesidad de establecer una cookie desde un controlador de ASP.NET WebApi (un ApiController). Por supuesto podríamos discutir largo y tendido sobre la conveniencia de hacer esto o no (si suponemos que dichos controladores van a ser accedidos por clientes que no sean navegadores y por lo tanto pueden no entender las cookies). Pero obviando esta discusión el problema está en que desde el controlador no podemos acceder al objeto Response (a diferencia de un controlador MVC tradicional). Por supuesto siempre existe la opción de usar HttpContext.Current pero eso no es deseable ya que ata mi controlador a un pipeline de ASP.NET por lo que pierdo la facilidad de pruebas.

La solución que he encontrado pasa por devolver un HttpResponseMessage desde el controlador. En mi caso la firma original del método era:

public AuthResultDTO PostLoginByUserPass(LoginDTO login)

{

}

El primer paso es modificarlo para que devuelva un HttpResponseMessage y usar el HttpResponseMessage para establecer las cookies.

Primero me he creado un método para que me crease la cookie (nota para curiosos: lo que quería hacer era usar un ticket de autenticación forms personalizado):

private static CookieHeaderValue CreateCustomCookie(string name, int id)

{

    var userData = id.ToString();

    var ticket = new FormsAuthenticationTicket(1, name, DateTime.Now, DateTime.Now.AddMinutes(30), false, userData);

    var encTicket = FormsAuthentication.Encrypt(ticket);

    var cookieValue = new CookieHeaderValue(FormsAuthentication.FormsCookieName, encTicket)

        {

            Path = "/",

            HttpOnly =  true,

        };

    return cookieValue;

}

Este método crea un ticket con un campo addicional (el id del usuario) y crea el objeto CookieHeaderValue que es el que contiene los datos de las cookies a añadir.

Ahora toca modificar el método del controlador. Lo primero es hacer que devuelva un HttpResponseMessage en lugar del AuthResultDTO que devolvía antes:

public HttpResponseMessage PostLoginByUserPass(LoginDTO login)

{

    var response = new HttpResponseMessage();

    return response;

}

El primer paso es añadir la cookie generada a nuestro mensaje:

var cookieValue = CreateCustomCookie(login.Name, id);

response.Headers.AddCookies(new CookieHeaderValue[] {cookieValue});

Pero ahora nos falta incrustar el AuthResultDTO dentro de la respuesta. Para ello debemos usar la propiedad Content del HttpResponseMessage (authResult es una variable de tipo AuthResultDTO):

response.Content = new ObjectContent(typeof(AuthResultDTO), authResult, new JsonMediaTypeFormatter());

Como vemos hemos de usar la clase ObjectContent ya que en mi caso quiero mandar el objeto serializado. El tercer parámetro indica que serializador se usa. En mi caso uso el serializador de JSON (JsonMediaTypeFormatter). Notad que aquí estoy fijando que la respuesta será siempre en JSON, con independencia de la cabecera Accept que me mande el cliente (contraviniendo lo que hace WebApi por defecto).

¡Y listos! Con eso ya hemos conseguido establecer nuestra cookie desde un controlador de WebApi.

Bonus track: ¿Cómo seleccionar el MediaTypeFormatter correcto?

Como he dicho antes el usar JsonMediaTypeFormatter directamente estoy “rompiendo” la capacidad de WebApi de seleccionar el tipo de respuesta según la cabecera Accept que envíe el cliente. Por suerte no es muy dificil restablecer dicha funcionalidad. Basta con mirar en la configuración global de WebApi todos los formatters que haya y encontrar el primero que pueda procesar el tipo especificado. Una posible implementación sería:

private MediaTypeFormatter ChooseMediaTypeFormatter(HttpHeaderValueCollection<MediaTypeWithQualityHeaderValue> accept, Type typeToWrite)

{

    var cfg = GlobalConfiguration.Configuration;

    foreach (var formatter in cfg.Formatters)

    {

        if (formatter.SupportedMediaTypes.Any(x => accept.Select(a => a.MediaType).Contains(x.MediaType)) &&

            formatter.CanWriteType(typeToWrite)) return formatter;

    }

 

    return new JsonMediaTypeFormatter();

}

Y llamaríamos a dicho método de la forma:

var mediaFormatter = ChooseMediaTypeFormatter(Request.Headers.Accept, typeof(AuthResultDTO));

Nota: Realmente esta implementación de ChooseMediaTypeFormatter no es del todo correcta ya que no tiene en cuenta la calidad especificada en la cabecera accept… Pero bueno, creo que la idea de como se podría hacer ya queda clara, no?

Saludos!

Actualización: Nicolás Herrera (@nicolocodev) me ha hecho dar cuenta de algo en lo que no he caído cuando he escrito el post. En un tweet me propone usar Request.CreateResponse en lugar de buscar manualmente el MediaTypeFormatter como estoy haciendo yo. Y tiene toda la razón del mundo 🙂 Anotado queda!

Información del Método (de extensión) CreateRequest.

Gracias! 😉

[Javascript] – null vs undefined

Buenas un post rapidito!! 😉

El otro día en un curso sobre patrones Javascript que estaba impartiendo surgió una de las dos(*) eternas dudas sobre Javascript. Uno de los alumnos (probablemente el único que estaba despierto) me preguntó “¿y cual es la diferencia exacta entre null y undefined?”.

Es curioso la desinformación que existe sobre este tema, cuando en realidad es muy simple. Por supuesto buscando por internet aparecen multitud de páginas sobre el tema, ¡pero es que he visto varias que están mal! P. ej. en una página donde se hablaba precisamente de esto, se decía:

    1. Una función siempre tiene que retornar un valor.
    2. Si algo es undefined no tiene valor por tanto una función nunca puede retornar undefined (me refiero a funciones propias de JavaScript)

Esas dos afirmaciones son falsas (a no ser que con el paréntesis final intente aclarar algo que no llego a entender) y además tienen que ver con el llamado “doble error de null” o el hecho de que un error anula a otro y todo parece correcto cuando en realidad… ¡hay dos errores!

Para empezar podemos ver que una función javascript puede perfectamente devolver undefined. Para una demostración rápida me voy a basar en el REPL que tiene Node.js:

image

Lo cierto es que es práctica común y errónea usar código como el siguiente para comprobar p.ej. si una variable (o propiedad) ha sido definida o un parámetro ha sido pasado:

if (login == null) { }

Esta simple línea contiene dos errores que se anulan uno al otro:

  1. El primer es usar null en lugar de undefined.
  2. El segundo es usar la comparación coercitiva (==) en lugar de la comparación estricta (===).

El código correcto debería ser:

if (login === undefined) { }

En javascript se usa undefined para indicar que algo no existe. Que no exista no significa que no tenga valor. Para indicar que algo existe pero no tiene valor se usa null. Piensa p. ej. que en javascript los argumentos de las funciones son opcionales: si quien llama a la función omite el argumento, este toma el valor de undefined. Pero a lo mejor quien nos llama a la función nos ha pasado el argumento pero sin valor: entonces será null. Lo mismo ocurre con las propiedades de los objetos, que en javascript como buen lenguaje dinámico pueden existir o no sobre la marcha.

El problema es que undefined !== null pero undefined==null y esa es la causa de toda la confusión. Cuando hacemos if (x == null) la comparación coercitiva intenta hacer conversiones de tipos y puede convertir entre el tipo undefined a null.

Realmente la comparación coercitiva (==) es una herramienta poderosísima y debería usarse con mucho cuidado. Por norma general deberías usar siempre === (y su contrario !==) para comparar. De esta manera te evitarías muchos errores y comportamientos extraños. Y echar mano del doble igual solo cuando es estrictamente necesario.

Saludos!

(*): Por cierto que la otra eterna duda (que también salió, como no) tuvo que ver sobre el volátil significado de this en javascript y también escribiré sobre ello.

¡Adiós 2012 y hola 2013!

Bueno… se ha terminado el 2012. Un año que ha traído dos cambios importantes en mi vida. Por un lado en Febrero nació mi hija Noa, lo que hizo que realmente todo fuese distinto y también, para que negarlo, que la cantidad de tiempo libre disminuyese exponencialmente. Y por otro en diciembre dejé raona para entrar a formar parte de pasiona y techdencias. No hay ninguna razón especial para dejar raona (un sitio donde he estado muy a gusto y donde se trabaja muy bien), solo que ya hacía demasiado tiempo que estaba allí y necesitaba un cambio de aires. Y una vez empecé a sondear el mercado el proyecto de pasiona me pareció muy interesante… Veremos 🙂

A nivel profesional ha sido un buen año: por un lado fuí nominado por primera vez como MVP y por otro hice algo que siempre había querido: impartir un curso on-line y fue la gente de desarrolloweb quienes me dieron la oportunidad de crear un curso de ASP.NET MVC para ellos. La experiencia fue muy enriquidora… ¡y en breve espero poder anunciar más noticias relacionadas con cursos on-line!

También a nivel personal con unos amigos nos juntamos y iniciamos una aventura que llamamos Epnuke. No sabemos como va a terminar, sólo que este 2013 le vamos a dedicar más ganas aún (si es que es posible).

Pero como he dicho el 2012 se ha ido y tras 12 campanadas ha llegado este 2013 que según los Mayas no debería haber existido jamás.

Y una de las tareas que realizo al principio de cada año es marcarme un conjunto de objetivos, o tareas que me gustaría hacer a lo largo del año. Luego intento planificarlas y así tener una especie de “calendario” a cumplir. Son siempre tareas al margen de mi vida laboral (desarrollo web y .NET) y muy genéricas (y relacionadas con el desarrollo por supuesto). P.ej. en el 2012 me planteé, las siguientes:

  1. Aprender un lenguaje funcional
  2. Aprender Unity3D
  3. Publicar un juego en la store de WP7
  4. Aprender desarrollo nativo en iOS (usando Objective C)

La primera la cumplí a medias (el lenguaje elegido fue scala aunqué he de reconocer que todavía me queda para poder decir que “sé” el lenguaje). La segunda sí la considero cumplida, y de hecho esta pasada BcnDevCon me animé a dar una charla sobre Unity3D. La tercera no la he cumplido, aunque he de decir que he aprendido a desarrollar para WP7 usando Silverlight primero y XNA después, pero no he llegado a publicar nada en la store. Y la cuarta la he cumplido a medias: he aprendido los fundamentos de Objective C y lo básico del desarrollo para iOS, pero a un nivel muy fundamental.

¿Y para ese 2013? Pues los objetivos que me he marcado son los siguientes:

  1. Seguir con Unity3D y publicar un juego hecho con él.
  2. Publicar un juego sencillo en la appstore, realizado con Objective C
  3. Publicar un juego sencillo en la store de Win8 / WP8. Estoy evaluando la tecnología y me gustaría mirarme SharpDX, aunque es más probable que al final termine tirando más por Monogame y así reaproveche mi conocimiento de XNA.

La verdad es que si cumplo dos de los tres me sentiré más que satisfecho. Y si cumplo los tres será para darme con un canto entre los dientes. ¿Lo conseguiré? Veremos… 😉

¿Y vosotros? ¿Qué objetivos tenéis planteados para el 2013?

Saludos!