Los navegadores son, cada vez más, los sistemas operativos modernos. A lo que me refiero es a que la mayoría de las aplicaciones que usamos en el día a día residen cada vez más en el navegador y menos en aplicaciones específicas en el escritorio. Por ello, desde HTML5 tenemos que poder hacer más cosas que tradicionalmente eran coto exclusivo de las aplicaciones de escritorio. Una de ellas es la posibilidad de enviar notificaciones ante ciertos eventos:

Chrome

Firefox

Gracias a la API de notificaciones de HTML5 es posible conseguirlo, aunque tiene sus detalles que debemos controlar.

Lee el post completo en JASoft.org: http://www.jasoft.org/Blog/post/Mostrando-notificaciones-desde-el-navegador-con-HTML5.aspx

Hace unas semanas Microsoft anunció la revisión 4.5.2 de .NET, que actualiza un poco la última versión de la plataforma .NET (la 4.5) con algunos ajustes y correcciones.

Si nos atenemos a lo que anunciaron en el blog oficial, e incluso en la lista de cambios del lanzamiento, no hay nada que llame la atención sobre un pequeño detalle que sin embargo es muy importante: han deshabilitado la posibilidad de desactivar el MAC del ViewState en ASP.NET Web Forms.

Y esto ¿qué significa?

Para verlo, primero demos un repaso rápido a qué es el MAC y para qué sirve. Luego veremos qué implicaciones tiene el hecho de no poder desactivarlo.

Funcionamiento del ViewState y autenticación

El ViewState, como todos deberíamos saber, es una parte fundamental del funcionamiento de Web Forms. Almacena el estado de los diferentes controles de una página entre postbacks. En Web Forms cada evento que se produce que se gestiona en el servidor implica un envío de la página de nuevo al servidor. A estos reenvíos se les conoce como PostBack. El servidor gestiona el evento (por ejemplo el clic de un botón) pero antes reconstruye el estado de todos los controles de la página para saber cómo se enviaron al cliente. De este modo es posible mantener todo como estaba, incluso en controles muy complejos como una rejilla, en cada ida y vuelta entre cliente y servidor, aunque se produzcan muchas veces en la misma página. Este «truco», aunque carga las páginas más de la cuenta, es muy efectivo y es la clave de que sea tan fácil programar con ASP.NET Web Forms.

El problema del ViewState es que, si alguien lo cambiase en el navegador antes de enviarlo de vuelta al servidor, podría engañar a la aplicación metiendo cualquier valor inapropiado en los controles. Por ejemplo, imagina una tienda on-line en la que un atacante cambiase los precios a su antojo. Dado que el ViewState se puede enviar al cliente sin encriptar (simplemente codificado como Base64), es muy fácil decodificarlo, modificarlo y volver a ponerlo con los cambios que queramos. En el peor de los casos un atacante hasta podría llegar a tomar el control de nuestro servidor.

Para evitar que esto ocurra, por defecto, ASP.NET Web Forms utiliza lo que se conoce como una verificación de autenticación de máquina o Machine Authentication Check (MAC). Básicamente el MAC consiste en agregar al final del ViewState un resumen digital o hash de los contenidos del mismo, encriptado usando una clave privada que solo conoce el servidor. Si al recibir de nuevo el ViewState tras un postback alguien hubiese cambiado los contenidos, sería muy fácil de detectar comprobando esa información cifrada y viendo que no coincide con la que se esperaría para ese contenido.

Es más fácil entenderlo si lo vemos paso a paso:

[…Continua en el post original…]

Lee el post completo en JASoft.org: http://www.jasoft.org/Blog/post/La-propiedad-EnableViewStateMac-ya-no-funciona-en-ASPNET-Web-Forms-452.aspx

Hasta la versión 2012 de Visual Studio disponíamos de un acceso directo muy cómodo desde el propio entorno que nos permitía lanzar la herramienta de configuración de ASP.NET:

De esta manera abríamos la utilidad que nos permitía configurar la seguridad de la aplicación: usuarios, roles, proveedores para éstos, etc…

En Visual Studio 2013 y .NET 4.5 se ha dado preferencia a las bibliotecas de ASP.NET Identityen detrimento del clásico sistema de Membership. Por ello, aparte de basar las nuevas plantillas de proyecto en estas nuevas bibliotecas de autenticación y autorización, se ha retirado el acceso directo a la herramienta anterior (y no se proporciona tampoco una herramienta análoga para lo nuevo, debiendo recurrir a la implementación por defecto incluida en las plantillas).

Sin embargo, si necesitas (o prefieres) utilizar el antiguo sistema de autenticación y te interesa acceder a la herramienta, todavía puedes hacerlo, aunque no te resultará tan cómodo.

El acceso se basa en el mismo truco que ya expliqué hace unos cuantos años para poder usar la herramienta fuera de Visual Studio…. [continúa en el enlace de abajo]

Lee el post completo en JASoft.org: http://www.jasoft.org/Blog/post/Acceder-a-la-herramienta-de-configuracion-de-ASPNET-en-Visual-Studio-2013.aspx