Amigo mío Siempre estas Programando en .NET

A veces puede ser muy útil decirle a Visual Studio que en vez de utilizar la ventana del navegador que normalmente tenemos abierta, que use una ventana de incognito para evitar cualquier tipo de cookie (En mi caso que no mezcle la mía de Live con una de Office 365) y así poder evitar problemas de logins y demás hierbas… 

Para configurar Visual Studio 2013 basta con ir a la barra de herramientas de View in browser:

Hacemos click en Browse with… y en la ventana hacemos click en el botón Add:

Google Chrome de incognito

• Program: C:Program Files (x86)GoogleChromeApplicationchrome.exe
• Arguments: –incognito
• Friendly name: “Lo que tu quieras”

Internet Explorer InPrivate:

• Program: C:Program FilesInternet Exploreriexplore.exe
• Arguments: –private
• Friendly name: “Lo que tu quieras”

Al final tendremos lo siguiente:

Y ya podemos depurar de manera privada.

Un saludo.

El próximo 27 de Marzo estaré junto a mis compañeros de Spenta hablando sobre Windows Azure en la oficinas de Microsoft Ibérica. A continuación os detallo la agenda:

Página de registro

09:30 – 10:15 Introducción y Novedades de Windows Azure
Veremos una breve introducción a Windows Azure y las últimas novedades que Microsoft ha lanzado en los últimos meses con respecto a esta tecnología.

10:15 – 11:15 Desarrollando aplicaciones web Real-time con SignalR en Azure
En esta charla veremos una introducción a SignalR, cómo funciona internamente y posteriormente profundizaremos en la mejor forma de desarrollar aplicaciones en tiempo real con SignalR y Azure.

11:15 – 11:30 Café

11:30 – 12:30 Diseña tu propio SharePoint Online utilizando Azure
En esta charla veremos cómo implementar una granja de servidores SharePoint en Windows Azure utilizando máquinas virtuales y servicios de Directorio Activo. Trataremos las ventajas, recomendaciones y buenas prácticas para diseñar nuestro propio entorno de SharePoint en la nube.

12:30 – 13:30 Desarrollando aplicaciones mobile (Cross Platform) con Azure Mobile Services
Windows Azure Mobile Services es la plataforma perfecta para construir el backend escalable de nuestras aplicaciones móviles de una manera sencilla. Nos provee de mecanismos para almacenamiento compartido, autenticación con Microsoft Account, Facebook, Twitter y Google, mandar notificaciones push, acceso a todos los servicios de la plataforma como son blobs, colas, service bus… y compatible con Windows Store y Phone 8, iOS, Android…

¿Donde?

¿Cuando?

El 27 de Marzo de 9:00 a 13:30

http://content.campaignspartner.com/mktd/landings/450e09dd-d40d-4bae-aca1-dd9a29549e8e

Os esperamos!

Hace tiempo que me ronda este post en la cabeza y nunca me he decidido a escribirlo. Hoy he sacado un poco de tiempo y he montado un ejemplo sobre lo peligroso que puede ser el no tratar con mucho cuidado la subida de archivos al servidor desde una aplicación web, en este caso ASP.NET WebForms, pero esto aplica también a MVC.

Código fuente:

https://github.com/lurumad/upload-files-vulnerability

La aplicación que he montado es supersencilla. Un página Default.aspx con un formulario que sube un archivo a un directorio que se llama Public. Imaginad que esta página es la página del perfil de usuario, donde cada usuario puede seleccionar su foto. Lo correcto sería restringir la extensión de los archivos a subir de tipo imagen (jpeg, jpg, png…), pero imaginad que el programador ha pasado por alto esta tarea no pensando lo que puede ocurrir porque no conoce que lo que está en el root del sitio web se ejecuta :p.

Ahora, un usuario un poco espabilado, le da por copiar la url de la foto de su pefil y se da cuenta que estamos subiendo dicha foto a una carpeta pública que se llama también Public, entonces dicho usuario se decide a probar si en dicho formulario de subida se está controlando el tipo de archivo que se sube. Se crea una página llamada HackPage.aspx junto con su archivo de Code Behind HackPage.aspx.cs y lo sube al servidor (Estos archivos los tenéis en el proyecto para que hagáis pruebas):

HackPage.aspx.cs lee el contenido del fichero Web.Config y lo muestra como fichero xml.

public partial class HackPage : System.Web.UI.Page

{

    protected void Page_Load(object sender, EventArgs e)

    {

        var serverPath = Server.MapPath("/");

        Response.Clear();

        Response.ClearHeaders();

        Response.ClearContent();

        Response.Buffer = true;

        Response.ContentType = "text/xml";

        Response.BinaryWrite(File.ReadAllBytes(Path.Combine(serverPath, "Web.Config")));

        Response.End();

    }

}

Teclea la url:

http://localhost:56023/public/hackpage

y… ¿Que creéis que ocurrirá?

Ojo! Esto es una prueba en local, pero estoy seguro que haciendo una búsqueda por Google no tardaría mucho en encontrar webs con este fallo de seguridad y por supuesto, esto no es una vulnerabilidad de ASP.NET, Tú has introducido una vulnerabilidad en tu aplicación web por no validar la subida de archivos a tu servidor.

Recomendaciones

1. Restringir el tipo de archivos que el usuario puede subir en nuestra aplicación.
2. Mover la carpeta de subida de ficheros fuera del root de la aplicación web. Siempre pudes usar un storage alternativo como SkyDrive, Dropbox, Azure Storage, Amazon S3…

Un saludo y Happy Coding!

Ayer tuve el placer junto con mi compañero Roberto González de participar en un webcast sobre Técnicas-Arquitectura-Experiencias personales… sobre CQRS con Windows Azure Service Bus y SignalR, donde transformamos en directo la aplicación MVC Music Store. No soy muy fan de los Webcast por el tema de tener que hablar con la pantalla, pero ayer al hacerlo conjuntamente se hizo más ameno y encima nos alargamos 40 min de tiempo. Cosas interesantes que resaltaría de ayer fue el uso de Visual Studio Anywhere ¿No  lo conoces? Corre insensato y descargalo!!! que gracias a Luis Fraile por el soporte que nos dió durante el evento montamos un experimento bastante interesante, ya que al ser dos ponentes teníamos que escribir código conjuntamente desde cada uno de nuestro equipos (Pair programming) y solo uno tenía la pantalla compartida. Además compartimos código con los asistente para que lo tuvieran online en su Visual Studio y pudieran seguir también el código en real.

Otra cosa que me gustaría resaltar y que quede muy claro: Es una demo!!!

Cosas que se quedaron en el tintero

Asincronía

Los CommandHandler se estaban ejecutando de manera síncrona:

namespace MvcMusicStore.CQRS.Core

{

    public interface ICommandHandler<T> where T : ICommand

    {

        void Execute(T command);

    }

}

Lo suyo sería aprovecharse de las ventajas de async/await que nos brinda el framework y hacerlos asíncronos para que nuestro servidor escale aún más, y más aún cuando la nueva versión de Entity Framework también lo soporta.

El CommandHandler quedaría algo como así:

namespace MvcMusicStore.CQRS.Core

{

    public interface ICommandHandler<T> where T : ICommand

    {

        Task ExecuteAsync(T command);

    }

}

Y nuestro controlador quedaría así:

[HttpPost]

public async Task<ActionResult> AddressAndPayment(FormCollection values)

{

    var order = new Order();

    TryUpdateModel(order);

    try

    {

        if (string.Equals(values["PromoCode"], PromoCode,

            StringComparison.OrdinalIgnoreCase) == false)

        {

            return View(order);

        }

        await _bus.SendAsync(

            new AddressAndPaymentCommand()

            {

                UserName = User.Identity.Name,

                OrderInfo = order   

            });

        return RedirectToAction("Complete");

    }

    catch

    {

        return View(order);

    }

}

Es importante que los métodos asíncronos tenminen con la palabra Async 😉

La presentación

El código

https://github.com/lurumad/mvc-musicstore-cqrs.git

Un saludo.

Mañana jueves 28 de Noviembre de 2013 a partir de las 19:30 tendrá lugar un webcast sobre desarrollo conjunto para Windows Phone y Windows 8 usando Portable Class Library y MVVMCross. Con este webcast se pretende enseñar los principios básicos que permite realizar desarrollos conjuntos para varias plataformas mediante Visual Studio, C# y XAML, y como llevarlos a la práctica en una caso real. Para poder seguirlo, debes registrarte en: https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032571013&Culture=es-ES&community=0. 

Andrés Lorbada y Christian Ruiz (Spenta) nos introducirán al patrón MVVM y al desarrollo de apps para Windows Phone y Windows 8 usando Portable Class Library y MVVMCross. Tras una brevísima introducción teórica, se realizará una demostración completamente práctica en la que se irá de menos a más.

Se comenzará con la realización de un pequeño ejemplo aplicando el patrón MVVM sin la utilización de ningún framework y, tras ello, se desarrollará una app desde cero mediante el uso de MVVMCross. El desarrollo de esta app irá evolucionando utilizando funcionalidades específicas de Windows Phone y Windows 8 hasta convertirse en una app totalmente funcional que emule un caso real.

Esperamos vuestra asistencia, ¡porque estamos seguros de que además de aprender algo nuevo lo vais a disfrutar!

En la primera versión de ASP.NET Web API cada vez que en una acción de un controlador queríamos crear una respuesta al usuario (Imaginaros un POST) y queríamos devolver algo más que el recurso  creado, por ejmplo el status code Created 201 y la url del mismo en la cabecera Location, teníamos que crearnos un HttpResponseMessage a mano y muchas veces caíamos en el error de tener código duplicado en nuestros controladores, algo como esto:

var response = Request.CreateResponse(HttpStatusCode.Created, user);

response.Headers.Location = 

    Url.Link("DefaultApi", new {controller = "Users", id = id});

return response;

Una de las novedades que me gusta mucho de ASP.NET Web API 2 es la llegada de IHttpActionResult, que básicamente es una interfaz que al implementarla dará como resultado una clase que actuará como una factoría de HttpResponseMessage y que podremos reutilizar en todas las acciones de los controladores que queramos. Así pues un ejemplo de uso sería el mencionado ejemplo que pusimos al principio de crear recursos vía POST:

public class CreatedActionResult : IHttpActionResult

{

    private readonly HttpRequestMessage _request;

    private readonly string _location;

    public CreatedActionResult(HttpRequestMessage request, string location)

    {

        _request = request;

        _location = location;

    }

    public Task<HttpResponseMessage> ExecuteAsync(CancellationToken cancellationToken)

    {

        var response = _request.CreateResponse(HttpStatusCode.Created); 

        response.Headers.Location = new Uri(_location);

        return Task.FromResult(response);

    }

}

Ahora tenemos el código centralizado en la clase CreatedActionResult y el pipeline de WebAPI llamará al método ExecuteAsync para crear la respuesta y podemos reutilizarlo en nuestros controladores:

public CreatedActionResult Post(string id, PostUserRequestModel requestModel)

{

    //Add user

    return new CreatedActionResult(Request, Url.Link("DefaultApi", new {controller = "Users", id = id}));

}

Estamos montando un proyecto en Azure Mobile Services y trabajando con Git, cuando instalamos algún paquete de node, a la hora de hacer stage de los ficheros nos encontramos con el siguiente error:

fatal: LF would be replaced by CRLF in service/table/node_modules/node-uuid/…

El problema viene dado por el EOL (End Of Line) que está en UNIX/OSX Format y nosotros estamos trabajando con Windows. Para verlo puedes descargarte Notepad++ y seleccionar “Show All Characters”

Así podemos ver el carácter EOL. Para cambiarlo a formato Windows, Menú Edit –> EOL Conversion –> Windows Format

Y voilá:

Ya podemos hacer stage, commit y push sin problemas.

Un saludo.

El viernes, 13 de septiembre de 2013 de 16:00 a 19:00 tendré el placer de colaborar con el Grupo de Ususrios de SharePoint de Madrid impartiendo una charla junto con mi compi Jorge Serrano sobre desarrollo en Windows 8 y Windows Phone 8. En mi caso mostraré como crear aplicaciones multiplataforma (Windows 8, Windows Phone 8, iOS, Android…) con MVVCross y así poder compartir el mayor número de líneas de código entre estas plataformas.

A continuación os dejo la url del evento:

https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032562294&Culture=es-ES&community=0

Un saludo.

Estoy montando el entorno de integración continua de la nueva versión de nuestro producto Beezy y a la hora de crear el paquete de despliegue me he encontrado con este error:

D:CIServerJenkinsjobs_PL 3. XXX PackageworkspaceapiXXXXXX.csproj(224,3): error MSB4019: The imported project "D:CIServerJenkinsjobs_PL 3. XXX PackageworkspaceapipackagesMicrosoft.Bcl.Build.1.0.7toolsMicrosoft.Bcl.Build.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

Parece ser que ha sido fallo de Microsoft en la última release de Nuget, concretamente en la feature de Enable Nuget Package Restore

Aquí podéis ver la issue y sus soluciones. Yo he tirado por modificar los csproj que me fallan al compilar y modificar esta línea:

<Import Project="….packagesMicrosoft.Bcl.Build.1.0.6toolsMicrosoft.Bcl.Build.targets" />

por esta otra:

<Import Project="….packagesMicrosoft.Bcl.Build.1.0.6toolsMicrosoft.Bcl.Build.targets" Condition="Exists(‘….packagesMicrosoft.Bcl.Build.1.0.6toolsMicrosoft.Bcl.Build.targets’)" />

A ver si la próxima vez antes de liberar la siguiente release lo prueban bien a fondo que he perdido día y medio con esta chorrada.

Un saludo.

Ayer estaba montando una nueva build para Beezy y como siempre que entro en nuestro servidor de Jenkins, compruebo que esté al día de actualizaciones, tanto el propio servidor como los plugins. Al realizar la actualización y reiniciarse el servidor me encontré con 2 problemas:

El primero este bonito error:

Como me gusta leerme bien los errores y stacktrace, me fije en esto:

Y pensé que tal vez algún plugin de maven estaba corrupto. Googleando encontré que se trata de este plugin:

maven-plugin.jpi.pinned

Y que está documentado aquí https://issues.jenkins-ci.org/browse/JENKINS-15892

Una vez elminado, mi servidor volvió a funcionar, pero me desaparecieron una serie de jobs. Volví a entrar en la configuración de Jenkins y observé que la actualización del servidor no se había realizado y me decía que había una nueva versión jenkins-1.518 pero la url no llevaba a ningún paquete war.

En la página oficial de Jenkins hablan de la versión 1.519, así pues decargué este war, lo actualicé y recuperé todos mis jobs. Ahora ya tengo mi servidor de CI actualizado y funcionando de nuevo.

Una de las cosas positivas que saco de todo esto, es que no siendo un experto en Jenkins, me ha gustado la manera en la que se puede solucionar un problema de este tipo sin tener que hacer reinstalaciones, backups… y sin perder mucho trabajo que ya estaba hecho

Un saludo.