Terry Pratchett ha sido uno de los grandes escritores de novelas de fantasía. Su serie más conocida Mundodisco, cuenta con 41 libros escritos en un estilo desenfadado y humorístico que parodian el género fantástico pero que a la vez encierran durísimas y mordaces críticas contra muchos aspectos de nuestra sociedad. El humor de Pratchett es reconocido como uno de los más ácidos e inteligentes a la vez que absurdos y esta mezcla es explosiva: sus libros te hacen estallar en carcajadas a la vez que reflexionar.

El modelo de binding que tiene WebApi es bastante más simple que el de MVC y por ello algunas tareas que en MVC eran más simples en WebApi pasan a ser un poco más complejas. Una de esas tareas es la subida de ficheros y de datos adicionales. A diferencia de MVC donde el contenido del cuerpo de la petición puede ser inspeccionado numerosas veces (según los value providers que tengamos configurados) en WebApi el cuerpo de la petición es un stream que puede ser leído una sola vez.

Ya hace bastante tiempo que NuGet salió y desde entonces se ha convertido en un compañero inseparable de todos nosotros. Y más que va a serlo cuando vNext salga de forma definitiva. En este post doy por supuesto que conoces NuGet y que lo has usado alguna vez (si no… ¡debes aprender a usarlo ya!). En este post quiero comentar los tres modos de funcionamiento que tiene NuGet y algunas cosillas más con las que me he encontrado.

En un cliente en el que he estado últimamente tenían un problema de rendimiento en su aplicación ASP.NET. El problema era más o menos que “cuando un usuario está buscando algo, entonces la aplicación se queda bloqueada”. Por supuesto el primer paso fue determinar que significaba “bloqueada” ya que es una palabra un tanto ambigua… Uno de los aspectos que conoce todo el mundo que trata con problemas reportados por usuarios finales es que muchas veces (por no decir casi siempre) el problema está descrito entre mal y peor.

El escenario que vamos a abordar en este post es el siguiente: tienes una API creada con ASP.NET WebApi y quieres que sea accesible a través de un token. Pero en este caso quieres ser tu quien proporcione el token y no un tercero como facebook, twitter o Azure Mobile Services (como p. ej. en el escenario que cubrimos en este post). Para ello nuestra API expondrá un endpoint en el cual se le pasarán unas credenciales de usuario (login y password) para obtener a cambio un token.

Seguro que muchos de vosotros conocéis Durandal, la librería para crear aplicaciones SPA ideada por Rob Eisenberg autor también de otras librerías como Caliburn y con cierta obsesión por las espadas… Hacé algún tiempo Rob anunció que se había unido al equipo de Angular para colaborar con el desarrollo de la versión 2.0 de dicha librería y que Angular y Durandal convergerían en una única librería. Eso generó muchas reacciones, algunas positivas, otras no tanto.

Buenas! El sábado (17 de Enero) tuve el placer de asistir al Bilbostack, una conferencia para desarrolladores que se celebra anualmente en Bilbao. En primer lugar felicitar a los organizadores porque la conferencia estaba muy bien montada: el sitio (la universidad de Deusto) era genial al igual que las dos salas usadas para los dos tracks paralelos que había. La primera, el auditorio, simplemente espectacular. La segunda, la sala Gárate, se quedó pequeña en alguna charla (la de IoT con gadgeeter que impartió Quique) pero bueno…

Estos días he estado desarrollando un aplicación de escritorio (wpf aunque eso es lo de menos) que va a hacer uso de LocalDb para guardar datos. Ciertamente no es un escenario muy habitual, ya que al instalar la aplicación en un ordenador cliente se requiere instalar LocalDb pero en este caso eso era asumible. Otras opciones para escritorio podrían pasar por usar algúna BBDD de proceso (como VistaDb o similares).

Hace algún tiempo escribí un post acerca de mecanismos para hacer tus servicios WebApi seguros. En este post mencionaba tres mecanismos para que tus servicios web solo sean accesibles a través de usuarios autenticados: Atributo Authorize custom: no recomendado para autenticación (es para autorización). Message Handler (DelegatingHandler): Mecanismo recomendado dentro de WebApi para autenticación. HttpModule: Solución a nivel de IIS. En el post comentaba que si tu aplicación depende de IIS puedes usar un HttpModule, pero que si quieres evitar tener una dependencia con él (ya que WebApi admite escenarios selfhost) debes usar un DelegatingHandler.

El escenario es el siguiente: tenemos un conjunto de servicios WebApi que no tienen porque estar desplegados en Azure pero queremos que esos servicios solo sean accesibles para usuarios que se hayan autenticado previamente a través de un proveedor externo (p. ej. Twitter) usando la infrastructura de Azure Mobile Services. Creación y configuración de Mobile Services Esa es la parte fácil… Una vez hemos creado nuestro mobile service debemos irnos a la pestaña Identity y colocar los valores que nos pide según el proveedor de autenticación externo que queramos usar.