• Artículo

Dentro de Microsoft.comAdministración y delegación de ASP.NET

Jeff Toews

La infraestructura Web de microsoft.com Web se basa casi por completo en .NET Framework 2.0. Uno de los retos clave de administración Web del equipo de operaciones de microsoft.com es la configuración adecuada de ASP.NET, sobre lo que hemos leído mucho intentando que nuestras configuraciones rozaran la perfección. Para conseguir

unos ajustes de configuración adecuados se necesita un buen conocimiento práctico de las distintas secciones de configuración de los archivos web.config y machine.config, y la comprensión de lo que significan esos ajustes. Una buena manera de encontrarle el truco a los ajustes y su relevancia es estudiar ejemplos. En esta columna, presentaré algunas sugerencias sobre configuraciones derivadas de la configuración de servidores con microsoft.com; de ese modo, podrá aprovecharse y aprender de nuestra experiencia.

1. Configurar el controlador de compilación adecuadamente

Al implementar aplicaciones basadas en ASP.NET en un entorno de producción, resulta de suma importancia asegurarse de que nadie deja sin querer (o deliberadamente) el atributo debug de compilación establecido en "true" en los archivos de aplicación web.config, como ocurre en el siguiente ejemplo:

<compilation debug="true" />

En entornos con mucho movimiento y muchas aplicaciones Web que administrar, puede que desee utilizar los mecanismos de control de configuración ASP.NET para evitar que esto ocurra. (Entraré en detalles más adelante.)

También es importante asegurarse de que el atributo de depuración específico para páginas no está establecido en "true" en .aspx individual como a continuación:

<%@ Page debug="true" %>

De nuevo, en entornos con mucho movimiento y grandes volúmenes de publicación, a menudo no resulta realista esperar que será capaz de garantizar que esta configuración se eliminará de todas las páginas .aspx antes de su publicación. Se necesitará un medio global para evitar que esto ocurra.

El hecho de compilar su aplicación Web con esta configuración dará como resultado datos binarios que deben ser depurados en lugar de datos binarios de distribución. Además, el código no se optimizará, lo que dará como resultado un rendimiento menor. Asimismo, las solicitudes ASP.NET no caducarán, pues los ajustes de depuración evitan que esto ocurra. La utilización de una versión de depuración en un entorno de producción es como abrir una puerta e invitar a los piratas informáticos.

Afortunadamente, Microsoft® .NET Framework 2.0 cuenta con un nuevo ajuste de implementación para machine.config que dice a ASP.NET que deshabilite los siguientes procesos: capacidades de depuración, resultado de seguimiento y mensajes de error de ASP.NET (tanto de forma remota como en el host local) independientemente de las instrucciones contenidas en el archivo web.config o en los atributos de página específicos. Tiene el siguiente aspecto:

<configuration>
    <system.web>
          <deployment retail="true"/>
    </system.web>
</configuration>

Hay que tener en cuenta que estas últimas dos ventajas (deshabilitar el resultado de seguimiento y los mensajes de error detallados de ASP.NET de manera remota) constituyen prácticas recomendadas de seguridad que deberían adoptarse. Si no se adoptan, se está exponiendo el funcionamiento interno de la aplicación al ataque por parte de cualquiera.

Siguiendo con el tema, aquí se presenta otro hecho importante: el bloqueo del atributo debug de <system.web><compilation> en el archivo raíz web.config dentro de <location allowOverride="false"> o la utilización del atributo lockItems evitará que los archivos web.config bajen en la jerarquía de configuración de la aplicación para convertirse en ajustes de depuración. Pero esto no evita que las páginas .aspx individuales habiliten el modo de depuración en sus atributos de página. El controlador de distribución de implementación constituye el único modo de deshabilitar totalmente las capacidades de depuración de ASP.NET en todos los niveles.

El hecho de establecer el controlador de distribución de implementación en "true" es probablemente el mejor método que una compañía con servidores de producción formales debería seguir para garantizar que una aplicación siempre se ejecute con el mejor rendimiento posible y sin pérdidas de información de seguridad. Como he dicho, este controlador es totalmente nuevo en ASP.NET 2.0; fue el resultado directo de los comentarios enviados al equipo de ASP.NET.

A la inversa, para entornos de preproducción enfocados al funcionamiento interno, en los que los desarrolladores necesitan depurar sus aplicaciones Web, no se deben utilizar ajustes de distribución de implementación. Simplemente hay que establecer <compilation debug="false"> en el archivo raíz de preproducción web.config de preproducción y permitir que este valor sea anulado por los archivos web.config de las aplicaciones individuales o los atributos de la páginas .aspx.

2. Utilizar un nivel de confianza medio en ASP.NET 2.0

Si, como fue el caso en muchos sitios de microsoft.com, aún se está utilizando un nivel de confianza completo o alto después de migrar el sitio o las aplicaciones a ASP.NET 2.0, eche otro vistazo a lo que ahora es posible llevar a cabo con un nivel de confianza medio. Por ejemplo, una WebPermission restringida obliga a las comunicaciones de la aplicación a utilizar sólo una dirección o un grupo de direcciones definidas en el elemento <trust>. Esta acción permite controlar y mantener una lista de sitios externos y grupos de direcciones aprobados a los que se puede llamar de forma remota. Esto constituye una gran ayuda en materia de seguridad.

FileIOPermission también está restringido. Este hecho se traduce en que el código de la aplicación sólo puede tener acceso a los archivos de su jerarquía virtual de directorios. En el nivel de confianza medio, de forma predeterminada, cada aplicación cuenta con permisos Read, Write, Append y PathDiscovery sólo para su jerarquía virtual de directorios. De esta forma, se pone fin al acceso aleatorio a la E/S de archivos, lo que resulta de gran importancia en entornos Web compartidos en los que se alojan muchas aplicaciones.

Otra ventaja es que se eliminan los privilegios de código sin administrar. Este hecho significa que se puede evitar el uso de componentes heredados, la manera más sencilla que hemos encontrado de deshabilitar la utilización del atributo de página Aspcompat. (El hecho de establecer Aspcompat en "true" puede ocasionar que el rendimiento de la página se degrade.)

El nivel de confianza medio en ASP.NET 2.0 es muy flexible en cuanto a la posibilidad que proporciona al administrador para crear excepciones personalizadas para cada restricción predeterminada previa. Esta flexibilidad no existía en ASP.NET 1.1. Otra razón por la que la ejecución en el nivel medio de seguridad con ASP.NET 2.0 es más sencilla que con ASP.NET 1.1 es que se cuenta con acceso a las bases de datos de Microsoft SQL Server™.

De este modo, si se alojan varias aplicaciones en el mismo servidor, se puede utilizar la seguridad de acceso al código y el nivel de confianza medio para contar con el aislamiento de la aplicación. Al ajustar y bloquear el nivel de confianza (mediante las etiquetas <location allowOverride="false">) en el archivo raíz web.config, se pueden establecer directivas de seguridad para todas las aplicaciones Web del servidor. Al establecer allowOverride="false", como se puede observar en la figura 1, un desarrollador individual no puede anular la configuración de directiva de confianza media en el archivo web.config de la aplicación.

Figure 1 Configuración de confianza

<configuration>
    <location allowOverride="false">
        <system.web>
            <securityPolicy>
                <trustLevel name="Full" policyFile="internal" />
                <trustLevel name="High" policyFile="web_hightrust.config" />
                <trustLevel name="Medium" policyFile="web_mediumtrust.config" />
                <trustLevel name="Low"  policyFile="web_lowtrust.config" />
                <trustLevel name="Minimal" policyFile="web_minimaltrust.config" />
            </securityPolicy>
            <trust level="Medium" originUrl="" />
        </system.web>
    </location>
</configuration>

Para obtener más información acerca del nivel de confianza medio en ASP.NET 2.0, consulte el siguiente artículo (puede estar en inglés): "How To: Use Medium Trust in ASP.NET 2.0 (Utilizar un nivel de confianza medio en ASP.NET 2.0).

3. Restringir la descarga de tipos de archivo específicos

Existen tipos de archivo en su servidor que sin duda no desea que caigan en malas manos. Afortunadamente, ASP.NET está configurado de forma predeterminada para interceptar y detener las solicitudes de muchos tipos de archivo distintos que se utilizan en aplicaciones ASP.NET. Se incluyen los archivos .config y .cs, que almacenan el código fuente de la aplicación. ASP.NET garantiza la privacidad de estos archivos al asociarlos con System.Web.HttpForbiddenHandler. Este controlador, cuando se invoca, devuelve un error al usuario que solicita el archivo. De hecho, puede utilizarse este método para restringir cualquier tipo de archivo.

Por ejemplo, en el sitio microsoft.com, el tipo de archivo .asmx se anula agregando la siguiente entrada a la sección del archivo raíz web.config <system.web><httpHandlers>:

<add path="*.asmx" verb="*" type=
    "System.Web.HttpForbiddenHandler" />

Como se puede observar, se pueden utilizar subetiquetas <add> en el elemento <httpHandlers> para especificar tipos de archivo adicionales que se desean bloquear. Establezca el atributo verb igual a "*". Al hacerlo, se especifica que todos los tipos de solicitud HTTP se bloquean para ese tipo de archivo. Defina el atributo path como un comodín que se corresponda con los tipos de archivo que desea bloquear. Por ejemplo, puede especificar "*.mdb". Por último, establezca el tipo de atributo en "System.Web.HttpForbiddenHandler".

4. Ser cuidadoso al agregar referencias de ensamblado

Todo servidor Web que ejecuta .NET Framework cuenta con una caché de código llamada caché de ensamblados global (GAC, del inglés "Global Assembly Cache"). La GAC almacena ensamblados específicamente diseñados para ser compartidos por múltiples aplicaciones del equipo. Tiene sentido agregar ensamblados a la GAC si varias aplicaciones distintas necesitan hacer referencia a ellos, incluso si la mayoría de los sitios del servidor Web no tienen acceso a ellos. El resultado no supone una penalización importante de rendimiento/recursos, sino que aporta la ventaja de mantener un control centralizado de la versión en lugar de ensamblados compartidos dispersos por el servidor en carpetas individuales /bin de la aplicación.

Los criterios para cuando un ensamblado hace una referencia deberían agregarse al archivo raíz web.config; sin embargo, han de ser mucho más estrictos que los criterios que dictan cuándo se ubica el ensamblado en la GAC. El hecho de contar con aplicaciones individuales que agregan referencias de ensamblado a sus archivos web.config para componentes que no son realmente globales revierte en un rendimiento mucho mejor que el obtenido declarando estas referencias en el archivo raíz web.config. Esto reduce considerablemente el tiempo de carga de la página para todas las aplicaciones del servidor Web que no utilizan estos ensamblados, ya que el compilador no emplea tiempo en cargar ensamblados innecesarios. El compilador ASP.NET no cargará un ensamblado para una aplicación simplemente porque el ensamblado resida en la GAC; sólo lo carga si la referencia de ensamblado existe en su appdomain o en una transacción app superior. Como resultado, en microsoft.com permitimos a los desarrolladores de aplicaciones que anulen el elemento <configuration><system.web><compilation><assemblies> en su archivo web.config para todos los entornos de Microsoft.com.

Especialmente en los archivos raíz web.config de los entornos de diseño y producción de microsoft.com, todos los atributos del nodo <system.web><compilation> están bloqueados (incluidos debug, explicit, defaultLanguage), así como todos sus elementos (buildProviders, expressionBuilders y similares), excepto el elemento <assemblies>:

<compilation debug="false" 
    explicit="true" defaultLanguage="vb" 
    numRecompilesBeforeAppRestart="500" 
    lockAttributes="*" lockAllElementsExcept=
        "assemblies" >

En el entorno de preproducción enfocado al funcionamiento interno, la sección <system.web><compilation> está bloqueada en el archivo raíz web.config, pero permitimos a los editores de la aplicación anular específicamente el elemento <assemblies> y debug="false" (para permitir la solución de problemas/depuración):

<compilation debug="false" explicit="true"
    defaultLanguage="vb" 
    numRecompilesBeforeAppRestart="500" 
    lockAllAttributesExcept="debug" 
    lockAllElementsExcept="assemblies" >

Observe el uso de atributos de bloqueo, nuevos en ASP.NET 2.0. Para obtener más información acerca de estos atributos y ejemplos de su uso, consulte "General Attributes Inherited by Section Elements" (Atributos generales heredados por elementos de sección).

5. Eliminar manualmente los valores MaxConnection

Casi todos los sitios Web de microsoft.com disponen de aplicaciones ASP.NET que llevan a cabo llamadas a agrupamientos de servicios Web remotos. El número máximo de llamadas simultáneas a servicios Web remotos que pueden realizarse desde un solo servidor Web queda determinado por el atributo maxConnection del elemento <connectionManagement> en el archivo machine.config. En ASP.NET 1.1, de forma predeterminada, el valor maxConnection se estableció en 2. Este antiguo valor maxConnection era demasiado bajo para sitios como microsoft.com, que cuentan con cientos de aplicaciones diferentes que realizan llamadas a servicios Web remotos. Como resultado, las solicitudes ASP.NET quedarían en cola mientras esperaban que se completaran las llamadas al servicio Web remoto. (Se puede ver el número de solicitudes ASP.NET en cola a través del contador perfmon ASP.NET\Requests Queued.) Para posibilitar la existencia de más llamadas para ejecutar simultáneamente un servicio Web remoto (y mejorar así el rendimiento de aplicaciones del sitio), aumentamos el valor de maxConnection hasta 40 para nuestros servidores Web de procesador quad. (El valor general recomendado para maxConnection es 12 veces el número de equipos, pero se debe ajustar a cada situación específica.)

Sin embargo, en ASP.NET 2.0 no se necesita configurar maxConnection manualmente, ya que se ajusta y configura automáticamente. Éste es el resultado de la nueva sección de configuración de la etiqueta processModel en machine.config (para obtener más información acerca del elemento processModel, consulte "processModel Element (ASP.NET Settings Schema)" —Elemento processModel (esquema de configuraciones ASP.NET)—).

<system.web>
    <processModel autoConfig="true" />
</system.web>

Con autoConfig habilitado en machine.config (configuración predeterminada), ASP.NET ajusta el valor del parámetro maxConnection a 12n (donde n representa el número de equipos). El hecho de habilitar autoConfig también provoca lo siguiente: los parámetros maxWorkerThreads y maxIoThreads se establecen en 100, el parámetro minFreeThreads se establece en 88n, el parámetro minLocalRequestFreeThreads se establece en 76n y minWorkerThreads en 50.

Antes de utilizar autoConfig en ASP.NET 2.0 para ajustar y establecer los valores de maxConnection y los otros atributos de la lista automáticamente, hay que asegurarse de eliminar cualquier valor establecido manualmente en estos parámetros, ya que estos valores se utilizarían en lugar de los valores de autoConfig. Esta situación debe tenerse en cuenta al migrar de ASP.NET 1.1 (donde maxConnection necesitaba establecerse explícitamente) a ASP.NET 2.0, donde los valores se establecen de forma predeterminada.

De nuevo, los valores autoConfig para maxConnection y los otros atributos incluidos en la lista anterior son algo arbitrarios y puede que no funcionen en todas las instancias, pero he comprobado que estos límites funcionan bien para casi todas las aplicaciones de microsoft.com.

Si decide ajustar los valores de maxConnection de forma manual, tenga cuidado al aumentarlos, pues puede llevar a un incremento en la utilización de la CPU. Este incremento se debe al hecho de que ASP.NET puede procesar más solicitudes entrantes en lugar de hacerles esperar su turno de llamada para el servicio Web. Por supuesto, recuerde que el atributo maxConnection no afecta a las llamadas de servicio Web locales, sólo a las llamadas remotas.

6. Cuidado con las excepciones no controladas

Al pasar de sitios Web o aplicaciones de ASP.NET 1.1 a ASP.NET 2.0, resulta muy útil tener presente un cambio principal en la directiva predeterminada para excepciones no controladas. En .NET Framework 1.1 y 1.0, las excepciones no controladas de subprocesos administrados se omitían y, debido a que las aplicaciones seguían ejecutándose, estas excepciones solían mantenerse escondidas. A menos que se incluyera un depurador para captar estas excepciones, nadie se daría cuenta de que algo funcionaba mal. Sin embargo, con ASP.NET 2.0, cuando se lanza una excepción no controlada, la aplicación basada en ASP.NET se cerrará de forma inesperada. Esto puede causar un grave impacto en la disponibilidad del sitio o la aplicación si existen muchas excepciones no controladas que estaban previamente ocultas por la antigua directiva predeterminada de control de excepciones.

La mejor forma de hacerle frente es realizar pruebas exhaustivas y eliminar las excepciones no controladas (que realmente no deberían estar presentes en la aplicación). No obstante, para migraciones de aplicaciones muy grandes en las que puede ser difícil determinar dónde ocurre la excepción o si se deben migrar muchas aplicaciones heredadas para las que es factible un proceso de prueba detallado e individual, se cuenta con un par de opciones. Al migrar el sitio Web microsoft.com a ASP.NET 2.0, cambiamos la directiva de excepciones no controladas de nuevo a su comportamiento predeterminado, como en ASP.NET 1.1 y ASP.NET 1.0.

Para habilitar este comportamiento predeterminado de control de excepciones heredado, se debe agregar el siguiente código al archivo aspnet.config:

<configuration>
    <runtime>
        <legacyUnhandledExceptionPolicy 
            enabled="true" />
    </runtime>
</configuration>

El código se encuentra en las dos siguientes carpetas:

%WINDIR%\Microsoft.NET\Framework\v2.0.50727 (en sistemas x86 o SYSWOW64) y %WINDIR%\Microsoft.NET\Framework64\v2.0.50727 (en sistemas x64).

Este cambio revertirá esencialmente el comportamiento de .NET Framework al de 1.1 y 1.0. Considérela una solución a corto plazo porque, en última instancia, se están enmascarando problemas de la aplicación que realmente constituyen errores. No obstante, resulta una forma muy práctica de evitar problemas en la disponibilidad debidos a procesos de trabajo que finalizan de forma inesperada. Para obtener más información acerca de los cambios de comportamiento, consulte "Unhandled exceptions cause ASP.NET-based applications to unexpectedly quit in the .NET Framework 2.0" (Las excepciones no controladas provocan que las aplicaciones basadas en ASP.NET se cierren de forma inesperada en .NET Framework 2.0).

7. Asegurar una configuración de servidor proxy correcta

Un administrador de servidor Web puede especificar el servidor proxy que se debe utilizar para las solicitudes HTTP a Internet configurando el elemento <configuration><system.net><defaultProxy> en el archivo machine.config.

En el entorno de producción de microsoft.com, se puede configurar el valor <defaultProxy> para utilizar el proxy predeterminado del sistema (ya que el cliente de firewall no está instalado) y utilizar las etiquetas <location allowOverride="false"> para evitar que el elemento <defaultProxy> sea anulado por los desarrolladores de aplicaciones (quienes pueden publicar accidentalmente un archivo web.config con un servidor proxy interno):

<configuration>
    <location allowOverride="false">
       <system.net>
          <defaultProxy>
              <proxy usesystemdefault="true" />
          </defaultProxy>
       </system.net>
    </location>
</configuration>

En los entornos de diseño y preproducción de microsoft.com, establecimos el atributo usesystemdefault en "false", bypassonlocal en "true" y agregamos una bypasslist de proxy (consulte la figura 2). La bypasslist muestra las expresiones regulares que describen las direcciones que no utilizan el proxy especificado. De nuevo, esta sección se contiene en las etiquetas <location allowOverride="false"> para evitar que los desarrolladores especifiquen su propio servidor proxy en los archivos web.config. (Estos servidores proxy son a menudo internos y las llamadas que se dirigen a ellos se interrumpen cuando las páginas se han publicado para producción.) Cualquier intento de especificar un servidor proxy en diseño o preproducción dará como resultado un error de ASP.NET en tiempo de ejecución que obligará a los desarrolladores a eliminar esta configuración antes de publicar para producción.

Figure 2 Configuración de Bypasslist

<configuration>
    <location allowOverride="false">
        <system.net>
             <defaultProxy>
                <proxy
usesystemdefault="false"
proxyaddress = "http://proxy.server.foo.com:80"
bypassonlocal = "true" />

                <bypasslist>
<add address="10\.*"/>
<add address="dns\.foo\.com" />
<add address="name1\.name2\.foo\.com" />
                </bypasslist>
            </defaultProxy>
        </system.net>
    </location>
</configuration>

8. No mostrar los errores personalizados

Como ya he mencionado, es de suma importancia no permitir que los mensajes de error detallados de ASP.NET sean devueltos de forma remota por los servidores Web en el entorno de producción.

En los archivos raíz web.config del entorno de diseño y producción de microsoft.com, el atributo de modo <configuration><system.web><customErrors> se establece en RemoteOnly, de manera que los errores personalizados se muestran a los clientes remotos y los errores de ASP.NET se muestran al host local (para permitir la solución de problemas por parte de los administradores del servidor Web). Hay que tener en cuenta que el elemento <customErrors> se contiene en una etiqueta <location> con allowOverride="false" (consulte la figura 3). Esto sirve para evitar que los propietarios de la aplicación individual establezcan sin querer (o deliberadamente) mode="Off" y publiquen los mensajes de error detallados de ASP.NET en Internet.

Figure 3 Evitar que se muestren mensajes de error

&lt;configuration&gt;
    &lt;location allowOverride='false'&gt;
        &lt;system.web&gt;
            &lt;customErrors mode='RemoteOnly' defaultRedirect=
                   '/errorpages/generic_customerror.aspx'&gt;
                &lt;error statusCode='404' redirect='/errorpages/filenotfound_customerror.aspx' /&gt;
            &lt;/customErrors&gt;
        &lt;/system.web&gt;
    &lt;/location&gt;
&lt;configuration&gt;

También conviene recordar, como mencioné anteriormente, que el uso del controlador <deployment retail="true"/> en el archivo machine.config desactiva la capacidad de mostrar mensajes de error detallados de ASP.NET tanto a clientes remotos como de forma local. Este controlador para distribución de implementación deberá continuar siendo el método principal para la desactivación de los mensajes de error si se utiliza ASP.NET 2.0. (Para obtener información detallada acerca de las excepciones ASP.NET, utilice el registro de sucesos de la aplicación.)

En el archivo raíz web.config del entorno de preproducción enfocado al funcionamiento interno de microsoft.com, el atributo de modo <customErrors> se establece en "off" para que los errores de ASP.NET se muestren siempre tanto a los clientes remotos como al host local. Esta acción se lleva a cabo para permitir la depuración y la solución de problemas. Asimismo, no se configuran las páginas de error personalizado:

<configuration>
    <location allowOverride="false">
        <system.web>
            <customErrors mode="Off" />
        </system.web>
    </location>
<configuration>

9. Saber cuándo habilitar el seguimiento

Los seguimientos de ASP.NET se generan durante la ejecución de una página ASP.NET, y capturan detalles interesantes sobre la solicitud Web, el árbol de control de la página, y la ejecución de diversas etapas del ciclo de vida y los controles de la página. Además, se pueden mostrar los mensajes personalizados que se pueden escribir para su seguimiento por parte del desarrollador de la página. El seguimiento se puede anexar al resultado de la respuesta de la página sometida a seguimiento o examinado como parte de la lista de solicitudes sometidas a seguimiento en el visualizador de seguimientos de la aplicación. Esta función está pensada principalmente para escenarios de depuración de tiempo de desarrollo en entornos de preproducción interna y no debe utilizarse en implementaciones de producción.

En los archivos raíz web.config de los entornos de diseño y producción de microsoft.com, el atributo habilitado <configuration><system.web><trace> está establecido en "false", de modo que la capacidad de producir información de seguimiento en una página Web queda deshabilitada. Hay que tener en cuenta que el elemento <trace> se contiene en una etiqueta <location> con allowOverride="false". Esto sirve para evitar que los propietarios de la aplicación individual establezcan sin querer (o deliberadamente) enabled="true" y publiquen información detallada de seguimiento de ASP.NET en Internet:

<configuration>
    <location allowOverride="false">
        <system.web>
              <trace enabled="false" localOnly="true"
              pageOutput="false" requestLimit="10" traceMode="SortByTime" />
        </system.web>
    </location>
<configuration>

<system.web><trace>

Como se mencionó anteriormente, el uso del controlador <deployment retail="true"/> en el archivo machine.config también desactiva la capacidad de proporcionar un resultado de seguimiento de ASP.NET en una página Web. Este controlador debería continuar siendo el método principal para la desactivación de los resultados de seguimiento si se ejecuta .NET Framework 2.0.

Para estar totalmente seguros de que no se puede habilitar sin querer el seguimiento en entornos de producción enfocados al exterior, en microsoft.com eliminamos el controlador trace.axd del archivo raíz web.config o hacemos lo siguiente:

<!--
<add path="trace.axd" verb="*" type=
    "System.Web.Handlers.TraceHandler"
    validate="True" />
-->

10. Deshabilitar granjas Web de estado de sesión

Ya que todos los sitios Web de microsoft.com están agrupados actualmente utilizando equilibrio de carga de red (NLB, del inglés "Network Load Balancing") sin afinidad (para permitir incluso la distribución de solicitudes entre servidores del agrupamiento), no existen garantías de que el mismo servidor controle todas las solicitudes de una aplicación determinada. Como resultado, el módulo de estado de sesión de ASP.NET se deshabilita para evitar que los desarrolladores de aplicaciones utilicen la propiedad Session. La directriz que damos a los desarrolladores de aplicaciones que necesitan mantener el estado es utilizar View State (que mantiene el estado de una estructura en el código de la página y, como resultado, no utiliza recursos del servidor).

Para deshabilitar el estado de sesión en un servidor Web, simplemente se debe eliminar el siguiente nodo hijo del nodo <httpModules>:

<add name="Session" type=
    "System.Web.SessionState.
    SessionStateModule"/>

Aquí he asumido que usted ya ha visto e incluso utilizado archivos de configuración de ASP.NET (machine.config, raíz web.config y archivos web.config de aplicación individual), pero si no lo ha hecho, le ayudará el tutorial "ASP.NET Quickstart Tutorial" (puede estar en inglés): asp.net/QuickStart/aspnet/doc/management/fileformat.aspx.

En el artículo se menciona que el sistema de configuración de ASP.NET 2.0 ahora incluye una serie de funciones muy útiles que permiten a los administradores bloquear elementos individuales y atributos de la configuración, utilizando los atributos lockItems y lockCollections. Estos atributos y su utilización están documentados en el artículo "General Attributes Inherited by Section Elements" (Atributos generales heredados por elementos de sección).

Jeff Toews es un administrador de ingeniería de sistemas miembro durante seis años del equipo de operaciones de Microsoft.com, con base en Redmond, Washington. Puede ponerse en contacto con él en referencia a cualquier comentario o duda técnica en mscomblg@microsoft.com.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.