Módulo_13_Configuración y despliegue de aplicaciones WEB

EL ARCHIVO WEB.CONFIG

© élogos Conocimiento, S.L. Madrid 2009. Todos los derechos de Propiedad Intelectual e Industrial de esta obra pertenecen a élogos Conocimiento, S.L.

ÍNDICE


1. Funciones del archivo. Principales opciones incluidas en web.config . . . . . . . . . . . . . . . . . .3

2. Registro de seguimiento de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

3. Modos de autenticación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

4. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19


3

1. Funciones del archivo. Principales opciones incluidas en web.config.

Objetivos y Estructura de la lección

1- Conocer las funciones del archivo y las principales opciones incluidas en Web.Config.2- Conocer el registro de seguimiento de aplicación.3- Conocer las principales características de los modos de autenticación.

Características del archivo Web.config

Web.config es el esencial archivo de configuración para una aplicación weben ASP.NET. El archivo es un documento XML que define información deconfiguración concerniente a la aplicación web.

El archivo Web.config contiene información que controla:

- la carga de módulos- configuraciones de seguridad- configuraciones del estado de la sesión- opciones de compilación- el lenguaje de la aplicación

Los archivos Web.config pueden contener también objetos específicos tales como cadenas de conexión a labase de datos.

Configuración del estado de sesión

El estado de sesión de ASP.NET permite almacenar y recuperar los valores deun usuario cuando el usuario explora diferentes páginas ASP.NET queconforman una aplicación Web.

HTTP es un protocolo sin estado, lo que significa que el servidor Web tratacada solicitud HTTP de una página, como una solicitud independiente; elservidor no retiene información alguna sobre los valores de las variables quese utilizan durante las solicitudes anteriores.

El estado de sesión de ASP.NET identifica las solicitudes recibidas desde elmismo explorador durante un período limitado de tiempo como una sesión,y proporciona la capacidad de conservar los valores de las variables durantela duración de esa sesión.

El estado de sesión de ASP.NET se habilita de forma predeterminada en todaslas aplicaciones ASP.NET.

Alternativas al estado de sesión

A continuación veremos distintas alternativas al estado de sesión:

- El estado de la aplicación, almacena variables a las que todos los usuarios de una aplicación ASP.NETpueden tener acceso.

- El espacio de nombres System.Web.Profile, mantiene los valores de usuario en un almacén de datossin que caduquen pasado un período de espera.

- El espacio de nombres System.Web.Caching, que almacena los valores de uso frecuente en unamemoria que está disponible a todas las aplicaciones ASP.NET.

- El espacio de nombres System.Web.UI.WebControls de ASP.NET, que mantiene los valores del controlen la propiedad ViewState.

- El objeto Cookies.

- El objeto QueryString.

- Los campos de un formulario HTML que están disponibles en un comando HTTP POST que utiliza lacolección Form.


4


5

Variables de sesión

- Se almacenan en la clase SessionStateItemCollection que está accesible a través de la propiedadSystem.Web.HttpContext.Session.

- La colección de las variables de sesión está iniciada por el nombre de la variable o por un índice deenteros.

- Las variables de sesión se crean sencillamente estableciendo referencias a la variable de sesión porel nombre.

- No necesita declarar una variable de sesión ni agregarla explícitamente a la colección.

Por ejemplo, en el ejemplo de código siguiente se crean variables de sesión para el nombre y el apellido deun usuario y se establecen en valores recuperados de los controles TextBox.

Visual Basic Session("FirstName") = FirstNameTextBox.TextSession("LastName") = LastNameTextBox.Text

C# Session["FirstName"] = FirstNameTextBox.Text;Session["LastName"] = LastNameTextBox.Text;

Tipo de variables de sesión

De forma predeterminada, las variables de sesión pueden ser de cualquiertipo .NET válido. Por ejemplo, en el ejemplo de código siguiente se almacenauna clase ArrayList de valores en una variable de sesión denominada"StockPicks“.

Ten en cuenta que el valor devuelto por la variable de sesión "StockPicks"debe transformarse en el tipo apropiado tras la recuperación deSessionStateItemCollection.


6

Cuando utiliza un modo de estado de sesión distinto de InProc, el tipo de la variable de sesión tipo, debe serun tipo .NET primitivo o serializable, porque el valor de la variable de sesión se almacena en un almacén dedatos externo.

Visual Basic ' When retrieving an object from session state, cast it as ' the appropriate type.Dim stockPicks As ArrayList = CType(Session("StockPicks"), ArrayList)' Write the modified stock picks list back to session state.Session("StockPicks") = stockPicks

C# // When retrieving an object from session state, cast it as // the appropriate type.ArrayList stockPicks = (ArrayList)Session["StockPicks"];// Write the modified stock picks list back to session state.Session["StockPicks"] = stockPicks;

Identificadores de sesión

Las sesiones se identifican mediante un identificador de sesión exclusivo quese puede leer utilizando la propiedad SessionID. Cuando el estado de sesiónse habilita en una aplicación ASP.NET, cada solicitud de una página de laaplicación se examina en busca de un valor SessionID enviado desde elexplorador. Si no se proporciona ningún valor SessionID, ASP.NET inicia unanueva sesión y el valor SessionID de esa sesión se envía al explorador con larespuesta.

De forma predeterminada, los valores SessionID se almacenan en una cookie,pero también se puede configurar la aplicación para que los valores SessionIDse almacenen en la dirección URL de una sesión "sin cookies".

Una sesión se considera activa siempre que las solicitudes continúenllevándose a cabo con el mismo valor SessionID. Si el tiempo entre lassolicitudes de una determinada sesión excede el valor de tiempo de esperaespecificado en minutos, la sesión se considera caducada. Si se realizansolicitudes con un valor SessionID caducado, se inicia una nuevasesión.


7

Eventos de sesión

ASP.NET proporciona dos eventos que ayudan a administrar las sesiones de usuario:

1. El evento Session_OnStart ==> que se desencadena cuando comienza una nueva sesión.

2. El evento Session_OnEnd ==> que se desencadena cuando se abandona una sesión o ésta caduca.

Los eventos de sesión se especifican en el archivo Global.asax de unaaplicación ASP.NET. Ten en cuenta que no se admite el eventoSession_OnEnd si la propiedad Mode de la sesión se establece en un valordistinto de InProc, que es el modo predeterminado.

Modificación del estado de sesión

Si se modifica el archivo Global.asax o el archivo Web.config de una aplicación ASP.NET, se reiniciará laaplicación y se perderá cualquier valor almacenado en el estado de la aplicación o en el estado de la sesión.

Ten en cuenta que algunos programas antivirus pueden actualizar la fecha y la hora de la última modificacióndel archivo Global.asax o Web.config de una aplicación.

Modos de sesión

El estado de sesión de ASP.NET es compatible con distintas opciones de almacenamiento de las variables desesión. Cada opción se identifica como un valor Mode del estado de sesión. El comportamientopredeterminado consiste en almacenar las variables de sesión en el espacio de memoria del proceso detrabajo de ASP.NET.


8

Sin embargo, también podemos especificar que el estado de sesión se almaceneen un proceso diferente, en una base de datos de SQL Server o en un origende datos personalizado. Si no se desea que el estado de sesión esté habilitadoen su aplicación, puede establecer el modo de sesión en Off.

Configurar el estado de sesión

El estado de sesión se configura utilizando el elemento sessionState de la sección de configuraciónsystem.web. También puede configurar el estado de sesión mediante la directiva de páginaEnableSessionState.

El elemento sessionState permite:

- Especificar el modo en el que la sesión almacenará los datos.- La manera en que los valores de identificación de sesión se envían entre el cliente y el servidor.- El valor Timeout de la sesión.- Y los valores que se admiten en función del valor de sesión Mode.

Por ejemplo, el elemento sessionState siguiente, configura una aplicación en el modo de sesión SQLServer,con un valor Timeout de 30 minutos, y especifica que los identificadores de sesión se almacenen en ladirección URL.

<sessionState mode="SQLServer"cookieless="true "regenerateExpiredSessionId="true "timeout="30"sqlConnectionString="Data Source=MySqlServer;Integrated Security=SSPI;"stateNetworkTimeout="30"/>


9

Deshailitación del estado de sesión

OffPuede deshabilitar el estado de sesión en una aplicación estableciendo elmodo de estado de sesión en Off.

FalseSi deseamos deshabilitar el estado de sesión solamente en una determinadapágina de una aplicación, podemos establecer la directiva de páginaEnableSessionState en false.

Ten en cuenta que la directiva de página EnableSessionState también se puede establecer en ReadOnly paraproporcionar acceso de sólo lectura a las variables de sesión.

Solicitudes simultáneas y estado sesión

El acceso al estado de sesión de ASP.NET es exclusivo para cada sesión, lo que significa que si dos usuariosdiferentes realizan solicitudes simultáneas, se concederá simultáneamente acceso a dos sesiones diferentes.

Sin embargo, si se realizan dos solicitudes simultáneas para la misma sesión (es decir, utilizando el mismovalor SessionID) la primera solicitud recibida tendrá acceso exclusivo a la información de la sesión, mientrasque la segunda solicitud se ejecutará cuando finalice la primera sesión o hasta que el bloqueo exclusivo dela información se libere porque la primera solicitud ha excedido el tiempo de espera del bloqueo.

Si la directiva de página EnableSessionState se establece en ReadOnly, una solicitud de sólo lectura de lainformación de sesión no produce un bloqueo exclusivo de los datos de la sesión. Es posible que las solicitudesde sólo lectura aún tengan que esperar a que se libere el bloqueo existente en una solicitud de lectura yescritura para los datos de la sesión.


10

2. Registro de seguimiento de la aplicación

Habilitar el seguimiento de nivel de aplicación

FalseEl seguimiento puede habilitarse para una aplicación completa en el archivo Web.config del directorio raízde la aplicación. De forma predeterminada, el seguimiento de nivel de aplicación se puede ver sólo en elequipo local del servidor Web. Para que la información de seguimiento de nivel de aplicación se pueda veren equipos remotos, estableceremos el valor del atributo localOnly del archivo Web.config en false.

TruePara proteger la aplicación Web, utilizaremos la capacidad de seguimiento remoto, únicamente cuandoprogramemos o instalemos la aplicación. Nos aseguraremos de que se deshabilita esta capacidad antes detransferir la aplicación a servidores Web de producción. Para deshabilitar el seguimiento remoto,establecemos el valor del atributo localOnly del archivo Web.config en true.

En el ejemplo siguiente se muestra una configuración de seguimiento de aplicación que recopila informaciónde hasta 40 solicitudes y permite que los exploradores de equipos distintos del servidor de origen muestrenel visor de seguimiento.

<configuration> <system.web> <trace enabled="true" requestLimit="40" localOnly="false"/></system.web></configuration>

Almacenamiento de solicitudes de seguimiento

Cuando se habilita el seguimiento para una aplicación, ASP.NET recopila la información de seguimiento decada solicitud realizada a la aplicación, hasta llegar al número máximo de solicitudes especificado. El númerode solicitudes predeterminado es 10. Cuando el visor de seguimiento alcanza este límite, la aplicación dejade almacenar solicitudes de seguimiento.

Cuando se habilita el seguimiento para toda la aplicación en el archivo Web.config, la información se recopilay procesa para cada página de la aplicación. Para deshabilitar el seguimiento de una página determinada,estableceremos false en el atributo Trace de la directiva @ Page de esa página.


11

Las instrucciones TraceContext Write o Trace Context Warn que incluya en elcódigo de una página se almacenan y se envían únicamente al visor deseguimiento.

Información de seguimiento

PageOutput

TrueSi deseamos que la información de seguimiento aparezca al final de la página a la que está asociada,estableceremos en true el atributo pageOutput de la sección de configuración de seguimiento del archivoWeb.config.

FalseSi deseamos que la información sólo aparezca en el visor de seguimiento,estableceremos false en este atributo.

Si habilitamos el seguimiento de nivel de aplicación, pero no deseamos quese muestre la información de algunas de sus páginas, utilizaremos la directiva@ Page para establecer false en el atributo Trace de esas páginas.

Atributos para modificar el comportamiento del seguimiento

La siguiente, es una lista de todos los atributos que pueden utilizarse para modificar el comportamiento delseguimiento de nivel de aplicación.


12

Habilitar el seguimiento para una aplicación

1. Crearemos un archivo de texto, asignaremos el nombre Web.config y lo guardaremos en el directorioraíz de la aplicación.

2. Entre las etiquetas de apertura y cierre del elemento <configuration>, agregaremos las etiquetasde apertura y cierre de un elemento <system.web>.

3. Entre las etiquetas del elemento <system.web>, agregaremos un elemento <trace>, que no requiereetiqueta de cierre.

4. En el elemento <trace>, declararemos el atributo enabled y lo estableceremos en true. 5. Declararemos los atributos opcionales que deseemos para modificar el comportamiento de

seguimiento de la aplicación.

Ejemplo para habilitar el seguimiento para una aplicación

Por ejemplo, la configuración de seguimiento de aplicación siguiente recopila información de hasta 40solicitudes y permite que los exploradores de equipos distintos del servidor de origen muestren el visor deseguimiento.

<configuration><system.web> <trace enabled="true" requestLimit="40" localOnly="false"/> </system.web></configuration>

En el sistema de configuración de ASP.NET se distingue entre mayúsculas y minúsculas. Los nombres de todaslas secciones de configuración que sólo contengan una palabra se escriben en minúsculas, mientras que enlos nombres de secciones y atributos formados por concatenaciones de dos palabras, la primera letra decada palabra concatenada es mayúscula. Por ejemplo, requestLimit es un nombre válido, pero requestlimitprovoca un error del analizador.


13

Ver la información de seguimiento con el visor de seguimiento

Una vez habilitado el seguimiento para una aplicación, cada vez que sesolicite una página de la aplicación se ejecutarán las instrucciones deseguimiento que contenga. Para ver estas instrucciones y la información deseguimiento adicional en el visor de seguimiento, solicitaremos Trace.axd enla raíz del directorio de aplicación.

Cuando se habilita el seguimiento para una aplicación, es posible ver las instrucciones de seguimiento y lainformación adicional en cualquier página de la aplicación con sólo establecer el valor true en el atributopageOutput en el archivo Web.config.

El visor de seguimiento permite elegir una solicitud específica entre las páginas solicitadas a la aplicación.En la siguiente imagen, se muestra un visor de seguimiento con las siete solicitudes enviadas a la aplicacióndesde que se habilitó el seguimiento.

Visor de seguimiento

Si se reciben múltiples solicitudes para una aplicación que tiene habilitado el seguimiento, en el visor deseguimiento aparecen las solicitudes en el orden en que se procesaron. La información de la página inicialdel visor de seguimiento incluye la hora de la solicitud, el archivo solicitado, el código de estado, el verboHTTP asociado y un vínculo Ver detalles que permite ver información más detallada acerca de la solicitud.El número de solicitudes mostradas no excederá el límite requestLimit especificado en el archivoWeb.config.


14

Destalles de seguimiento de una solicitud específica

1. Nos desplazaremos al visor de seguimiento asociado con la aplicación Por ejemplo, si la dirección URL de la aplicación es http://localhost/myapplication, iremos ahttp://localhost/myapplication/trace.axd para ver las estadísticas de seguimiento.

2. Seleccionaremos el vínculo Ver detalles de la solicitud que deseemos investigar Una vez seleccionado Ver detalles, veremos la misma información que se agregó a la página que tenía elseguimiento habilitado.

En algunas circunstancias, puede ser conveniente quitar todas las solicitudesalmacenadas en el visor de seguimiento. Quizás deseemos hacer unseguimiento de los cambios de los archivos de la aplicación o simplementever información sobre archivos distintos de los asociados a las solicitudesmostradas.

Borrado de las solicitudes del visor de seguimiento

1. Nos desplazaremos al visor de seguimiento asociado a la aplicación.

2. Seleccionamos el vínculo borrar rastro actual para quitar todas las solicitudes almacenadas en laaplicación del visor de seguimiento.

El visor de seguimiento sólo se ocupará de las solicitudes realizadas después de borrar el registro. Lassolicitudes efectuadas después de alcanzar el límite establecido y antes de borrar el registro no puedenvisualizarse.


15

3. Modos de autenticación

Team Foundation Server, Autenticación básica y Autenticación implícita

Team Foundation Server con Service Pack 1 (SP1) puede admitir los modos deautenticación básica e implícita. Si configuramos la implementación de TeamFoundation Server para que utilice HTTPS con Secure Sockets Layer (SSL) yla autenticación básica o implícita, se podrán realizar conexiones externascon Team Foundation Server sin tener que utilizar una conexión de redprivada virtual (VPN).

Configuraciones

Para admitir las conexiones externas con sus implementaciones de TeamFoundation Server, debemos configurar Servicios de Internet InformationServer (IIS) para habilitar la autenticación básica o implícita. Además,debemos configurar un filtro de Interfaz de programación de aplicacionespara servidores de Internet (ISAPI).

Los filtros ISAPI son archivos DLL que se pueden utilizar para modificar ymejorar la funcionalidad proporcionada por IIS. Los filtros ISAPI siempre seejecutan en un servidor que ejecuta IIS. Debemos configurar el filtro ISAPIque forma parte del Service Pack 1 con las direcciones IP de los servidores proxy Web o los clientes que deban utilizar la autenticación básica o implícita.

Autenticación básica

La autenticación es parte de la especificación de HTTP 1.0. Utiliza cuentas de usuario de Windows. Durantela autenticación básica, el explorador solicita al usuario un nombre de usuario y una contraseña.

La información de nombre de usuario y contraseña se transmite a través de HTTP utilizando la codificaciónBase64. De forma predeterminada, la autenticación básica requiere que la cuenta de usuario de Windowstenga derechos de inicio de sesión local en el servidor Web.

Se puede utilizar la autenticación básica en implementaciones de grupode trabajo y de dominio. Aunque la mayoría de los servidores Web, servidoresproxy y exploradores Web admiten la autenticación básica, no es segura.


16

Dado que es fácil descodificar los datos codificados en Base64, con la autenticación básica, la contraseña seenvía esencialmente como texto sin formato. Alguien que supervise las comunicaciones en la red podríainterceptar y descifrar fácilmente estas contraseñas utilizando herramientas disponibles al público.

Autenticación implícita

La autenticación implícita es un mecanismo de desafío y respuesta que envíaa través de la red un resumen (también denominado hash) en lugar de unacontraseña. Durante la autenticación implícita, IIS envía un desafío al clientepara crear un resumen y después lo envía al servidor.

Como respuesta al desafío, el cliente envía un resumen basado en lacontraseña del usuario y datos que conocen tanto el cliente como el servidor.El servidor utiliza el mismo proceso que el cliente para crear su propioresumen, y utiliza la información del usuario obtenida de Active Directory.

Si el resumen creado por el servidor coincide con el resumen creado por el cliente, IIS autentica el cliente.La autenticación implícita sólo se puede utilizar en implementaciones de dominio de Active Directory. Por sísola, la autenticación implícita es simplemente una pequeña mejora de la autenticación básica. Un intrusopodría registrar la comunicación entre el cliente y el servidor, y utilizar esa información para reproducir latransacción.

Limitaciones

Además de los requisitos de grupo de trabajo y dominio antes mencionados,la autenticación básica e implícita no son suficientes por sí solas paraproporcionar seguridad de red para los clientes externos, por consiguiente,no deberíamos configurar Team Foundation Server para admitir clientesexternos a menos que también configuremos estas conexiones para querequieran HTTPS con SSL.


17

Configuración del filtro ISAPI

El filtro ISAPI se puede configurar para imponer reglas en un conjunto de direcciones IP dado.

Aunque la mayoría de los administradores se interesarán principalmente por la configuración de las reglasdel filtro ISAPI para las direcciones IP externas, también se pueden configurar reglas para las direccionesinternas. Cualquier dirección IP configurada en las reglas del filtro ISAPI deben seguir las reglas que seespecifican en el filtro. Dependiendo de la configuración de RequireSecurePort, las direcciones que no seespecifiquen en el archivo pueden conectarse o no a Team Foundation Server.

El filtro ISAPI utiliza un archivo AuthenticationFilter.ini para sus valores de configuración. Debemos configurareste archivo con los valores adecuados para su implementación. El archivo puede utilizar las claves y valoresde configuración siguientes:


18

Definición de claves

Las claves se definen más detalladamente de la manera siguiente:

- RequireSecurePort: Si configuramos RequireSecurePort como True, todas las conexiones deben utilizarHTTPS/SSL y la autenticación básica o implícita, a menos que se utilicen las direcciones especificadasen SubnetList. Si configuramos RequireSecurePort como False, sólo las conexiones que utilicen lasdirecciones especificadas en ProxyIPList deberán utilizar HTTPS/SSL y la autenticación básica oimplícita.

- ProxyIPList Dirección o direcciones IP para las que deseamos imponer la autenticación básica oimplícita. La manera más fácil de definir esta clave es considerarla como "Requerir sólo laautenticación básica o implícita para estas direcciones". Las direcciones especificadas para esta clavedeberán utilizar la autenticación básica o implícita y HTTPS/SSL. Esta clave tiene prioridad sobreSubnetList; si está presente la clave ProxyIPList, se omitirán la clave SubnetList y sus valores.

- SubnetList: Par o pares de direcciones IP y máscaras de subred para los que no deseamos imponer laautenticación básica o implícita. La manera más fácil de definir esta clave es considerarla como"Requerir que todas las direcciones menos éstas utilicen la autenticación básica o implícita". Lasdirecciones especificadas para esta clave no deberán utilizar la autenticación básica o implícita yHTTPS/SSL. Las direcciones no especificadas para esta clave deberán utilizar la autenticación básicao implícita. Si la clave ProxyIPList está presente en el filtro ISAPI, se omitirán la clave SubnetList ysus valores.


19

4. Resumen

Has llegado al final de esta lección de formación que denominamos “El archivo Web.config”. En esta lección hemos estudiado los siguientes contenidos:

PERSONALIZACIÓNDE APLICACIONES

ASP.NET EN TIEMPODE DESPLIEGUE


PERSONALIZACIÓN DE APLICACIONES ASP.NET ENTIEMPO DE DESPLIEGUE

2

Definición de claves en Web.config

Nuevas opciones de configuración

La mayoría de las características de ASP.NET requieren elementos adicionales al esquema de la configuraciónde ASP.NET. Algunas características requieren elementos adicionales a las secciones existentes, mientras queotras características requieren nuevas secciones. En la siguiente tabla se describen los nuevos elementos deconfiguración en ASP.NET 2.0. Estos elementos adicionales del esquema se reflejan en la nueva API deconfiguración de ASP.NET, en el complemento MMC de ASP.NET y, cuando es apropiado, en la herramientaAdministración de sitios Web.


3


4

Ver el esquema de configuración y la configuración predeterminada

Ver los archivos de comentarios de Machine.config y Web.config que se encuentran en el directorio%SystemRoot%\Microsoft .NET\Framework\versionNumber\CONFIG. El sistema de configuración no utilizaestos archivos para configurar las aplicaciones, pero contienen listas de configuración predeterminada ycomentarios útiles.

Funciones del explorador

La sección browserCaps está deprecada en la versión 2.0. de .NET Framework. Para la compatibilidad conversiones anteriores, los valores de configuración de esta sección siguen siendo efectivos si se definen en elnivel de la aplicación, pero se combinan con la información incluida en los archivos de definición delexplorador (.browser) situados en el directorio %SystemRoot%\Microsoft.NET\Framework\versionNumber\CONFIG\Browsers del equipo y las carpetas App_Browser de la aplicación existentes.


5

Ventajas de la utilización de claves.

Configurar el controlador de compilación adecuadamente

Al implementar aplicaciones basadas en ASP.NET en un entorno de producción, resulta de suma importanciaasegurarse de que nadie deja sin querer (o deliberadamente) el atributo debug de compilación establecidoen “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 losmecanismos de control de configuración ASP.NET para evitar que esto ocurra. 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 resultarealista esperar que será capaz de garantizar que esta configuración se eliminará de todas las páginas .aspxantes 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 debenser 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 dedepuración evitan que esto ocurra. La utilización de una versión de depuración en un entorno de producciónes 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 paramachine.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áginaespecí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 losmensajes de error detallados de ASP.NET de manera remota) constituyen prácticas recomendadas deseguridad que deberían adoptarse. Si no se adoptan, se está exponiendo el funcionamiento interno de laaplicació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 lautilización del atributo lockItems evitará que los archivos web.config bajen en la jerarquía de configuraciónde la aplicación para convertirse en ajustes de depuración. Pero esto no evita que las páginas .aspxindividuales habiliten el modo de depuración en sus atributos de página. El controlador de distribución deimplementación constituye el único modo de deshabilitar totalmente las capacidades de depuración deASP.NET en todos los niveles.

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

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


6

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ás utilizando un nivel de confianza completoo alto después de migrar el sitio o las aplicaciones a ASP.NET 2.0, echa otro vistazo a lo que ahora es posiblellevar 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 unadirección o un grupo de direcciones definidas en el elemento <trust>. Esta acción permite controlar ymantener una lista de sitios externos y grupos de direcciones aprobados a los que se puede llamar de formaremota. 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 puedetener acceso a los archivos de su jerarquía virtual de directorios. En el nivel de confianza medio, de formapredeterminada, cada aplicación cuenta con permisos Read, Write, Append y PathDiscovery sólo para sujerarquía virtual de directorios. De esta forma, se pone fin al acceso aleatorio a la E/S de archivos, lo queresulta 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 puedeevitar el uso de componentes heredados, la manera más sencilla que hemos encontrado de deshabilitar lautilización del atributo de página Aspcompat. (El hecho de establecer Aspcompat en “true” puede ocasionarque 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 aladministrador para crear excepciones personalizadas para cada restricción predeterminada previa. Estaflexibilidad no existía en ASP.NET 1.1. Otra razón por la que la ejecución en el nivel medio de seguridad conASP.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 MicrosoftSQL Server™.

De este modo, si se alojan varias aplicaciones en el mismo servidor, se puede utilizar la seguridad de accesoal código y el nivel de confianza medio para contar con el aislamiento de la aplicación. Al ajustar y bloquearel 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 establecerallowOverride=”false”, un desarrollador individual no puede anular la configuración de directiva de confianza media en el archivo web.config de la aplicación.


7

<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>

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 muchostipos de archivo distintos que se utilizan en aplicaciones ASP.NET. Se incluyen los archivos .config y .cs, quealmacenan el código fuente de la aplicación. ASP.NET garantiza la privacidad de estos archivos al asociarloscon System.Web.HttpForbiddenHandler. Este controlador, cuando se invoca, devuelve un error al usuario quesolicita 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 ala 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> paraespecificar tipos de archivo adicionales que se desean bloquear. Establezca el atributo verb igual a “*“. Alhacerlo, se especifica que todos los tipos de solicitud HTTP se bloquean para ese tipo de archivo. Defina elatributo 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”.


8


9

Ser cuidadoso al agregar referencias de ensamblado

El servidor Web que ejecuta .NET Framework tiene con una caché de código llamada caché de ensambladosglobal (GAC, del inglés “Global Assembly Cache”). La GAC almacena ensamblados específicamente diseñadospara ser compartidos por múltiples aplicaciones del equipo. Tiene sentido agregar ensamblados a la GAC sivarias aplicaciones distintas necesitan hacer referencia a ellos, incluso si la mayoría de los sitios del servidorWeb 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 ensambladoscompartidos 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 enla GAC. El hecho de contar con aplicaciones individuales que agregan referencias de ensamblado a susarchivos web.config para componentes que no son realmente globales revierte en un rendimiento muchomejor que el obtenido declarando estas referencias en el archivo raíz web.config. Esto reduceconsiderablemente el tiempo de carga de la página para todas las aplicaciones del servidor Web que noutilizan 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 ensambladoresida en la GAC; sólo lo carga si la referencia de ensamblado existe en su appdomain o en una transacciónapp superior. Como resultado, en microsoft.com permitimos a los desarrolladores de aplicaciones que anulenel elemento <configuration><system.web><compilation><assemblies> en su archivo web.config para todos losentornos 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 elelemento <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 anularespecíficamente el elemento <assemblies> y debug=”false” (para permitir la solución deproblemas/depuración):

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

Eliminar manualmente los valores MaxConnection

Casi todos los sitios Web de microsoft.com disponen de aplicaciones ASP.NET que llevan a cabo llamadas aagrupamientos de servicios Web remotos. El número máximo de llamadas simultáneas a servicios Web remotosque pueden realizarse desde un solo servidor Web queda determinado por el atributo maxConnection delelemento <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 concientos de aplicaciones diferentes que realizan llamadas a servicios Web remotos. Como resultado, lassolicitudes ASP.NET quedarían en cola mientras esperaban que se completaran las llamadas al servicio Webremoto. (Se puede ver el número de solicitudes ASP.NET en cola a través del contador perfmonASP.NET\Requests Queued.) Para posibilitar la existencia de más llamadas para ejecutar simultáneamente unservicio Web remoto (y mejorar así el rendimiento de aplicaciones del sitio), aumentamos el valor demaxConnection hasta 40 para nuestros servidores Web de procesador quad. (El valor general recomendadopara maxConnection es 12 veces el número de equipos, pero se debe ajustar a cada situaciónespecífica).


10

En ASP.NET 2.0 no se necesita configurar maxConnection manualmente, ya que se ajusta y configuraautomáticamente. Éste es el resultado de la nueva sección de configuración de la etiqueta processModel enmachine.config

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

</system.web>

Con autoConfig habilitado en machine.config (configuración predeterminada), ASP.NET ajusta el valor delparámetro maxConnection a 12n (donde n representa el número de equipos). El hecho de habilitar autoConfigtambién provoca lo siguiente: los parámetros maxWorkerThreads y maxIoThreads se establecen en 100, elparámetro minFreeThreads se establece en 88n, el parámetro minLocalRequestFreeThreads se establece en76n y minWorkerThreads en 50. Antes de utilizar autoConfig en ASP.NET 2.0 para ajustar y establecer los valores de maxConnection y losotros atributos de la lista automáticamente, hay que asegurarse de eliminar cualquier valor establecidomanualmente 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 necesitabaestablecerse 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 sonalgo arbitrarios y puede que no funcionen en todas las instancias, pero he comprobado que estos límitesfuncionan bien para casi todas las aplicaciones de microsoft.com. Si decide ajustar los valores de maxConnection de forma manual, tenga cuidado al aumentarlos, pues puedellevar a un incremento en la utilización de la CPU. Este incremento se debe al hecho de que ASP.NET puedeprocesar 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óloa las llamadas remotas.

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 cambioprincipal en la directiva predeterminada para excepciones no controladas. En .NET Framework 1.1 y 1.0, lasexcepciones no controladas de subprocesos administrados se omitían y, debido a que las aplicaciones seguíanejecutándose, estas excepciones solían mantenerse escondidas. A menos que se incluyera un depurador paracaptar 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


11

la aplicación si existen muchas excepciones no controladas que estaban previamente ocultas por la antiguadirectiva 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 aplicacionesmuy grandes en las que puede ser difícil determinar dónde ocurre la excepción o si se deben migrar muchasaplicaciones heredadas para las que es factible un proceso de prueba detallado e individual, se cuenta conun par de opciones. Al migrar el sitio Web microsoft.com a ASP.NET 2.0, cambiamos la directiva deexcepciones no controladas de nuevo a su comportamiento predeterminado, como en ASP.NET 1.1 y ASP.NET1.0. Para habilitar este comportamiento predeterminado de control de excepciones heredado, se debe agregarel 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érelauna solución a corto plazo porque, en última instancia, se están enmascarando problemas de la aplicaciónque realmente constituyen errores. No obstante, resulta una forma muy práctica de evitar problemas en ladisponibilidad debidos a procesos de trabajo que finalizan de forma inesperada.


12

Asegurar una configuración de servidor proxy correcta

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

En el entorno de producción de microsoft.com, se puede configurar el valor <defaultProxy> para utilizar elproxy 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 losdesarrolladores de aplicaciones (quienes pueden publicar accidentalmente un archivo web.config con unservidor proxy interno):


<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.

La bypasslist muestra las expresiones regulares que describen las direcciones que no utilizan el proxyespecificado. De nuevo, esta sección se contiene en las etiquetas <location allowOverride=”false”> paraevitar que los desarrolladores especifiquen su propio servidor proxy en los archivos web.config. (Estosservidores proxy son a menudo internos y las llamadas que se dirigen a ellos se interrumpen cuando laspáginas se han publicado para producción).

Cualquier intento de especificar un servidor proxy en diseño o preproducción dará como resultado un errorde ASP.NET en tiempo de ejecución que obligará a los desarrolladores a eliminar esta configuración antes depublicar para producción.


13


<system.net><defaultProxy>

<proxyusesystemdefault=”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>

No mostrar los errores personalizados

Es de suma importancia no permitir que los mensajes de error detallados de ASP.NET sean devueltos de formaremota 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 errorespersonalizados 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 sinquerer (o deliberadamente) mode=”Off” y publiquen los mensajes de error detallados de ASP.NET en Internet.


14

Evitar que se muestren mensajes de error :

<configuration><location allowOverride="false">

<system.web><customErrors mode="RemoteOnly" defaultRedirect=

"/errorpages/generic_customerror.aspx"><error statusCode="404"

redirect="/errorpages/filenotfound_customerror.aspx" /></customErrors>


<configuration>

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

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


<system.web><customErrors mode=”Off” />


<configuration>


15

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 detallesinteresantes sobre la solicitud Web, el árbol de control de la página, y la ejecución de diversas etapas delciclo de vida y los controles de la página. Además, se pueden mostrar los mensajes personalizados que sepueden escribir para su seguimiento por parte del desarrollador de la página. El seguimiento se puede anexaral resultado de la respuesta de la página sometida a seguimiento o examinado como parte de la lista desolicitudes 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óninterna 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 atributohabilitado <configuration><system.web><trace> está establecido en “false”, de modo que la capacidad deproducir información de seguimiento en una página Web queda deshabilitada. Hay que tener en cuenta queel elemento <trace> se contiene en una etiqueta <location> con allowOverride=”false”. Esto sirve para evitarque 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:


<system.web><trace enabled=”false” localOnly=”true”pageOutput=”false” requestLimit=”10” traceMode=”SortByTime” />


<configuration>

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


16

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

<!—<add path=”trace.axd” verb=”*“ type=

“System.Web.Handlers.TraceHandler”validate=”True” />

—>

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 dered (NLB, del inglés “Network Load Balancing”) sin afinidad (para permitir incluso la distribución desolicitudes entre servidores del agrupamiento), no existen garantías de que el mismo servidor controle todaslas solicitudes de una aplicación determinada. Como resultado, el módulo de estado de sesión de ASP.NET sedeshabilita 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 ViewState (que mantiene el estado de una estructura en el código de la página y, como resultado, no utilizarecursos del servidor). Para deshabilitar el estado de sesión en un servidor Web, simplemente se debe eliminar el siguiente nodohijo del nodo <httpModules>:

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

Se ha asumido que ya se 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).


17

Lectura de una clave desde una aplicación ASP.NET.

Cómo preparar el fichero web.config

En primer lugar, crearemos la sección appSettings en el fichero de configuración web.config. La crearemosdentro del nivel configuration pero fuera del nivel system.web tal y como os muestro a continuación.

<configuration><system.web>...</system.web><appSettings>

<add key=”CADENA_CONEXION” value=”Provider=XXX;Data Source=XXX;UserId=XXX;Password=XXX;database=XXX;”/>

<add key=”NUMERO_NOTICIAS_PORTADA” value=”10”/><add key=”ADSENSE_ACTIVADO” value=”false”/>

</appSettings></configuration>

Como podéis ver en el ejemplo, dentro de la sección que acabamos de crear, introduciremos la clave y valor(la clave podéis elegirla a vuestro gusto) de las tres variables que íbamos a manejar desde el web.config,tal y como habíamos comentado anteriormente.

Cómo leer esta configuración desde la aplicación web

Para almacenar la información, vamos a crear una clase estática con un método Init que se encargará deinicializar las variables y que sólo será llamado una vez, al arrancar la aplicación.

Por si acaso, almacenaremos los datos en variables privadas y crearemos sólamente las propiedades Get, deesta forma evitaremos que se pueda modificar directamente o por un descuido el valor de estas variables,ya que sólo podrán ser modificadas a través del método Init. El constructor privado sirve para impedir quepuedan crearse objetos de esta clase, ya que únicamente nos interesa como clase estática.

public class Configuracion {private static string m_cadenaConexion = “”;private static int m_numeroNoticiasPortada = 0;private static bool m_adsenseActivado = false;

private Configuracion() { }


18

public static Init(string cadenaConexion, numeroNoticiasPortada, adsenseActivado) {m_cadenaConexion = cadenaConexion;m_numeroNoticiasPortada = numeroNoticiasPortada;m_adsenseActivado = adsenseActivado;

}

public string CadenaConexion { get { return m_cadenaConexion;} }public int NumeroNoticiasPortada { get { return m_numeroNoticiasPortada;} }public bool AdsenseActivado { get { return m_adsenseActivado;} }

}

Una vez hecho esto, sólo nos queda leer la configuración. Para ello utilizaremos el método Application_Startdel fichero global.asax, ya que se ejecuta sólamente una vez, al iniciarse la aplicación.

public class Global : System.Web.HttpApplication {public Global() {}...protected void Application_Start(Object sender, EventArgs e) {

string cadenaConexion =System.Configuration.ConfigurationManager.AppSettings[“CADENA_CONEXION”];

int numeroNoticiasPortada =Convert.ToInt32(System.Configuration.ConfigurationManager.AppSettings[“NUMERO_NOTICIAS_PORTADA”]);

bool adsenseActivado =Convert.ToBoolean(System.Configuration.ConfigurationManager.AppSettings[“ADSENSE_ACTIVADO”]);

Configuracion.Init(cadenaConexion, numeroNoticiasPortada, adsenseActivado);}...

}

Para leer uno de los valores de configuración, utilizaremos la sentenciaSystem.Configuration.ConfigurationManager.AppSettings[“clave“], donde clave es la clave que habíamosescogido anteriormente.

Hay que tener en cuenta que la sentencia anterior sólo nos dará los valores como strings, tal y como aparecenen el fichero web.config. Por lo tanto, para leer valores enteros o booleanos, tendremos queconvertir ese string al tipo de dato correspondiente igual que en el ejemplo.


19

TÉCNICAS PARA ASEGURAR

APLICACIONES


ÍNDICE

TÉCNICAS PARA ASEGURAR APLICACIONES

1. Funciones del archivo. Principales opciones incluidas en web.config . . . . . . . . . . . . . . . . . . .3

2. Técnicas de autenticación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

3. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13


3

1. Funciones del archivo. Principales opciones incluidas en web.config

Objetivos y Estructura de la lección

1- Conocer los conceptos fundamentales sobre seguridad en aplicaciones Web. 2- Conocer las distintas técnicas de autenticación.

Control de acceso de información

ASP.NET, conjuntamente con Microsoft Internet Information Services (IIS), puede autenticar las característicasdel usuario como nombres y contraseñas mediante los métodos siguientes:

- Windows: básica, implícita, y autenticación de Windows integrada (NTLM o Kerberos).

- Autenticación mediante formularios, con la que crea una página de inicio de sesión y se administrala autenticación en la aplicación.

- Autenticación mediante certificados de cliente.

ASP.NET controla el acceso a la información de los sitios comparando las credenciales autenticadas, orepresentaciones de las mismas, con los permisos del sistema de archivos de Microsoft Windows NT o con unarchivo XML que contiene la lista de usuarios autorizados, funciones autorizadas (grupos) o verbos HTTPautorizados.

Seguridad en los sitios web

La seguridad de los sitios Web es una cuestión de importancia fundamental, además de compleja, para losdesarrolladores de sitios Web. La protección de un sitio requiere la elaboración cuidadosa de un plan; porconsiguiente, los programadores y administradores de sitios Web deben comprender perfectamente lasopciones para proteger los sitios.


4

ASP.NET funciona junto con Microsoft .NET Framework y Servicios de Microsoft Internet Information Services(IIS) para ayudar a proporcionar aplicaciones Web seguras. Para ayudar a proteger la seguridad de unaaplicación ASP.NET, se deben llevar a cabo las dos funciones principales que se describen en la siguientetabla.

Descripción de las funciones de seguridad

Además, Internet Information Services (IIS) puede conceder o negar el acceso en función de la dirección IPo del nombre de host del usuario. Cualquier autorización de acceso posterior se realiza mediante laautorización de la dirección URL del permiso de acceso al sistema de archivos NTFS.

Es importante entender cómo interactúan todos los diversos subsistemas de seguridad. Puesto que ASP.NETse basa en Microsoft .NET Framework, el desarrollador de aplicaciones ASP.NET también tiene acceso a todaslas características de seguridad integradas de .NET Framework, como la seguridad de acceso a códigoy la seguridad de acceso basada en funciones.


5

2. Técnicas de autenticación

La autenticación es un proceso que consiste en obtener las credenciales deidentificación, como nombre y contraseña, de un usuario y validarlasconsultando a una autoridad determinada. Si las credenciales son válidas, seconsidera a la entidad que ha enviado las credenciales como una entidadautenticada. Una vez autenticada la identidad, el proceso de autorizacióndetermina si esa identidad tiene acceso a un recurso específico.

ASP.NET implementa este proceso a través de proveedores de autenticación, que son módulos que contienenel código necesario para autenticar las credenciales del solicitante.

Autenticación basada en Windows

La Autenticación de Windows trata la identidad de usuario proporcionada porServicios de Microsoft Internet Information Services (IIS) como el usuarioautenticado en una aplicación ASP.NET.

IIS

IIS ofrece diversos mecanismos de autenticación para comprobar la identidad del usuario, incluyendoautenticación anónima, autenticación de Windows integrada (NTLM), autenticación de Windows integrada(Kerberos), autenticación básica (codificada en base64), autenticación de texto implícita y autenticaciónbasada en certificados de cliente.

- La autenticación de Windows se implementa en ASP.NET utilizandoel módulo Windows AuthenticationModule. El módulo construye unaidentidad WindowsIdentity basándose en las credencialesproporcionadas por IIS y establece la identidad como el valor actualde la propiedad User para la aplicación.

- La autenticación de Windows es el mecanismo de autenticación predeterminado para las aplicacionesASP.NET y se identifica como el modo de autenticación para una aplicación mediante el elemento deconfiguración authentication, tal como se muestra en el ejemplo de código siguiente.

<system.web><authentication mode="Windows"/>

</system.web>


6

Suplantar la identidad de Windows

Si bien el modo de autenticación de Windows establece el valor de lapropiedad User actual en una identidad WindowsIdentity basándose en lascredenciales proporcionadas por IIS, no modifica la identidad de Windowsproporcionada al sistema operativo.

La identidad de Windows proporcionada al sistema operativo se utiliza paracomprobar los permisos, como los permisos de archivos NTFS, o paraconectarse a una base de datos mediante la seguridad integrada.

De forma predeterminada, esta identidad de Windows es la identidad del proceso de ASP.NET. En MicrosoftWindows 2000 y Windows XP Professional, ésta es la identidad del proceso de trabajo de ASP.NET, que es lacuenta local de ASPNET.

En Windows Server 2003, ésta es la identidad del Grupo de aplicaciones IIS del que forma parte la aplicaciónASP.NET. De forma predeterminada, ésta es la cuenta NETWORK SERVICE.

Suplantar la identidad de Windows: Parte 2

Para configurar la identidad de Windows de la aplicación ASP.NET como laidentidad de Windows proporcionada por IIS, hay que habilitar lasuplantación, es decir, indica a la aplicación ASP.NET que suplante laidentidad suministrada por IIS para todas las tareas autenticadas por elsistema operativo Windows, incluyendo el acceso a archivos y a la red.

Para habilitar la suplantación para la aplicación Web, en el archivo Web.config de la aplicaciónestableceremos el atributo impersonate del elemento identity en true, como se muestra en el ejemplo decódigo siguiente:

<system.web><authentication mode="Windows"/><identity impersonate="true"/>

</system.web>


7

Habilitar la autorización utilizando ACL de NTFS

Podemos mejorar la seguridad de una aplicación ASP.NET si protegemos losarchivos de la aplicación mediante el sistema de archivos NTFS y Listas decontrol de acceso (ACL). Las ACL permiten especificar qué usuarios y gruposde usuarios tienen acceso a los archivos de la aplicación.

Autenticación basada en formularios

La autenticación de formularios permite autenticar el nombre de usuario y la contraseña de los usuariosmediante un formulario de inicio de sesión que hayamos creado.

Las solicitudes no autenticadas se redirigen a una página de inicio de sesión, en la que el usuario proporcionalas credenciales y envía el formulario. Si la aplicación autentica la solicitud, el sistema emite un vale quecontiene una clave con el fin de restablecer la identidad para posteriores solicitudes.

Para personalizar la forma en que se trata el vale de autenticación de losformularios y cómo se establece la propiedad User, se puede controlar elevento FormsAuthentication_OnAuthenticate en el archivo Global.asax de laaplicación. Aunque es normal permitir a la autenticación de formulariosadministrar estas tareas, las aplicaciones podrían incluir requisitosespecíficos, como el establecimiento de la propiedad User para una clasepersonalizada que implementa la interfaz principal. En esos casos, laaplicación debería controlar el evento FormsAuthentication_OnAuthenticatey encargarse de la administración de la cookie.

Autenticación de formularios entre distintas aplicaciones

ASP.NET admite la autenticación mediante formularios en un entorno distribuido, ya sea entre aplicacionesen un solo servidor o en una matriz de servidores Web. Cuando la autenticación de formularios se habilitaen las varias aplicaciones ASP.NET, no es necesario que los usuarios vuelvan a autenticarse al cambiar entrelas aplicaciones.

8

Configurar la autenticación de formularios a través de aplicaciones

Para configurar la autenticación de formularios a través de aplicaciones,debemos establecer varios atributos en las secciones de configuración formsy machineKey de forma que los valores sean los mismos para todas lasaplicaciones que participan en la autenticación de formularios compartidos.

Ejemplo de Autenticación basada en formularios

El ejemplo siguiente muestra la sección Authentication de un archivo Web.config. A menos que se indiquelo contrario, los atributos name, protection, path, validationKey y decryptionKey deben ser idénticos entodas las aplicaciones. Del mismo modo, las claves de codificación y validación, por un lado, y el esquemade codificación utilizado para los datos de las cookies, por otro, deben ser exactamente iguales. Si nocoinciden los valores, no se pueden compartir las cookies.

<configuration><system.web><authentication mode="Forms" ><forms loginUrl="login.aspx"name=".ASPXFORMSAUTH" protection="All" path="/" timeout="30" />

</authentication>

<machineKey

validationKey="C50B3C89CB21F4F1422FF158A5B42D0E8DB8CB5CDA1742572A487D9401E3400267682B202B746511891C1BAF47F8D25C07F6C39A104696DB51F17C529AD3CABE"

decryptionKey="8A9BE8FD67AF6979E7D20198CFEA50DD3D3799C77AF2B72F" validation="SHA1" />

</system.web></configuration>


9

Autenticación basada en formularios

Tras emitir una cookie, se realiza un seguimiento de su vencimientobasándose en el valor de Expires dentro de la propia cookie.

Esto significa que si dos aplicaciones tienen diferentes atributos TimeOut, la hora y la fecha de vencimientoestablecidas cuando se emitió la cookie se conservan a lo largo de toda la vida útil de la cookie.

Cuando se actualiza una cookie, se utiliza su vencimiento original para calcular la nueva fecha devencimiento. La única vez que se utiliza el valor de configuración de TimeOut es cuando se crea inicialmentela cookie.

Autorización de usuarios y Acceso restringido a recursos

Limitar el acceso a los sitios Web ASP.NET

La limitación del acceso a una aplicación suele dividirse en dos temas:

- Autenticación, que es cómo una aplicación identifica quién eres. - Autorización, que es cómo una aplicación identifica cuáles son sus permisos.

Este tema ofrece una información general de la autenticación y la autorización en las aplicaciones WebASP.NET.

Autenticar a usuarios

Las aplicaciones ASP.NET ofrecen varias opciones diferentes para autenticar a los usuarios. En el caso de lasaplicaciones de sólo lectura que puede ver cualquiera, utilizaremos la autenticación anónima. Para tener unacceso más restringido a una aplicación, debemos utilizar algún tipo de autenticación para identificar a losusuarios. Hay dos identidades que debemos tener en cuenta a la hora de autenticar a los usuarios de suaplicación ASP.NET: la identidad de la aplicación que se utiliza para tener acceso a los recursos de Windowsy la identidad de usuario de ASP.NET que se utiliza para identificar a un usuario ante ASP.NET.

Autorización de usuarios y Acceso restringido a recursos

La aplicación puede ejecutarse sin una identidad de usuario de ASP.NET, pero siempre tendremos unaidentidad de aplicación para Windows. Para ayudar a proteger la aplicación, debemos restringir la identidadde Windows para la aplicación a los recursos necesarios, como el acceso a archivos y a bases de datos.

Cuando una página ASP.NET está en ejecución, el servidor debe tener uncontexto de seguridad, o identidad, para el proceso que está ejecutando elcódigo ASP.NET. Esta identidad se utiliza al proteger recursos mediante laseguridad integrada de Windows, como los archivos protegidos mediante elsistema de archivos NTFS o recursos de red.

Por ejemplo, sólo la identidad de aplicación ASP.NET tiene que leer los archivos que contienen el código deaplicación almacenado en el subdirectorio App_Code de una aplicación.

Por tanto, se puede restringir la configuración de seguridad de los archivos del directorio App_Code demanera que la identidad de aplicación ASP.NET sólo tenga acceso de lectura. Otro uso frecuente de laidentidad de Windows de la aplicación ASP.NET es como identidad de una conexión a SQL Server medianteseguridad integrada.

Hay varios factores que determinan la identidad de una aplicación ASP.NET.

- De forma predeterminada, las páginas ASP.NET se ejecutan con la identidad de Windows del servicioque procesa las páginas ASP.NET en el servidor Web.

- En un equipo que ejecuta Windows Server 2003, esa identidad es la identidad del grupo deaplicaciones del que forma parte la aplicación ASP.NET (de manera predeterminada, la cuentaNETWORK SERVICE).

- En los equipos que ejecutan Windows 2000 y Windows XP Professional, la identidad es la cuenta localASPNET que se crea cuando se instala .NET Framework. Esta identidad se puede configurar a unaidentidad diferente, si se desea.

La identidad de Windows

Podemos modificar la identidad de Windows con la que se ejecuta la página ASP.NET mediante el elementoidentity de la sección system.web del archivo de configuración. El elemento identity puede utilizarse paraindicar a ASP.NET que suplante un Id de usuario de Windows.

La suplantación de una identidad de Windows significa que las páginas ASP.NET para la aplicación seejecutarán como esa identidad de Windows. Podemos especificar un nombre de usuario y una contraseña parasuplantar.


10

Como alternativa, podemos habilitar la suplantación, y ASP.NET se ejecutaráde una de dos maneras posibles:

1. una identidad anónima especificada por IIS

2. una identidad del explorador autenticada determinada por IIS (porejemplo, autenticación anónima, autenticación de Windows integrada(NTLM), etc.)

Si suplantamos a Windows, podemos ejecutar código que revierta a la identidad original del proceso en lugardel Id de usuario suplantado.

- Por eso, en aquellos entornos en los que tengamos que mantener separadas las aplicaciones unas deotras, debemos aislarlas en grupos de aplicaciones diferentes en equipos que ejecuten WindowsServer 2003. Cada grupo de aplicaciones debe configurarse con una identidad de Windows única.

- Podemos determinar fácilmente la identidad de Windows del subproceso del sistema operativo queestá ejecutando la página ASP.NET mediante la propiedad Name del Windows Identity devuelto porel método GetCurrent, como se muestra en el ejemplo de código siguiente:

<%=System.Security.Principal.WindowsIdentity.GetCurrent().Name%>

Usuario de ASP.NET

La identificación se utiliza para tener acceso a recursos específicos de ASP.NET. Por ejemplo, podemosidentificar una parte de una aplicación para que sólo esté disponible para determinados usuarios, mientrasque otras partes de la aplicación estarán disponibles para todos los usuarios.


11


12

El elemento authentication de la sección system.web del archivo Web.config de la aplicación, determina elusuario de ASP.NET. Tenemos varias opciones para autenticar la identidad de ASP.NET para nuestra aplicación:

- Podemos utilizar el nombre de usuario de Windows determinado por IIS.

- Autenticación de formularios de ASP.NET.

- Autenticación Passport.

- Un esquema de autenticación personalizado.

- Se puede tener acceso a la identidad de ASP.NET utilizando la propiedad User del HttpContext actual.

Si estamos utilizando autenticación de formularios de ASP.NET o una soluciónde autenticación personalizada para proporcionar la identidad de ASP.NET,podemos utilizar la pertenencia de ASP.NET para ofrecer funcionalidad dealmacén de datos de usuarios y administración de usuarios.

Autorizar a usuarios

La autorización es a todos los efectos restringir el acceso de los usuarios sólo a los recursos necesarios. Estoincluye restringir el acceso sólo a los archivos, las bases de datos y las partes de su aplicación que seannecesarios. Además, esto incluye el uso de Seguridad de acceso a código para restringir el acceso al código.

Podemos restringir el acceso a archivos utilizando listas de control de acceso de NTFS yFileAutorizationModule.

Podemos restringir el acceso a determinadas partes de nuestra aplicación utilizando UrlAutorizationModuley Administración de funciones de ASP.NET.


13

3. Resumen

Has llegado al final de esta lección de formación que denominamos “Técnicas para asegurar aplicaciones”.

En esta lección hemos estudiado los siguientes contenidos:

INSTALACIÓN DE UNA

APLICACIÓN ENUN SERVIDOR IIS


INSTALACIÓN DE UNA APLICACIÓN EN UN SERVIDOR IIS

2

Creación de directorios virtuales y sitios Web.

Los siguientes pasos muestran cómo marcar un directorio como directorio raíz de la aplicación medianteServicios de Internet Information Server (IIS) 5.0 o una versión posterior.

Se explica también cómo crear un directorio virtual y cómo establecer el directorio C:\Inetpub\Wwwrootcomo directorio raíz de la aplicación.

Crear el directorio físico

Cree un nuevo directorio físico. La primera sección de este tutorial utiliza el directorio C:\exampleWebApp.

Cree un nuevo directorio físico en el directorio C:\Inetpub\Wwwroot. La segunda sección de este tutorialutiliza el directorio C:\Inetpub\Wwwroot\exampleWebApp.

Abrir el Administrador IIS

Abra el Administrador de Internet Information Services (IIS) por medio de uno de los procedimientossiguientes.

Para abrir el Administrador IIS desde un símbolo del sistema: - En el menú Inicio, haga clic en Ejecutar. - En el cuadro de diálogo Abrir, escriba inetmgr y, después, haga clic en Aceptar.Para abrir el Administrador IIS con un miembro de la familia de Windows Server 2003: - Haga clic en Inicio, seleccione Herramientas administrativas y, a continuación, haga clic en Administrador de Internet Information Services (IIS).Para abrir el Administrador IIS en Windows XP: - En el menú Inicio, haga clic en el Panel de control. - Si no lo ha hecho todavía, haga clic en Cambiar a Vista clásica. - Haga doble clic en Herramientas administrativas y, a continuación, haga doble clic en Servicios de Internet Information Server.Para abrir el Administrador IIS en Windows 2000: - En el menú Inicio, seleccione Aplicaciones, Herramientas administrativas y haga clic en Administrador de servicios Internet.

Crear una asignación de directorio virtual

Utilice el procedimiento siguiente para crear un directorio virtual que esté asignado a un directorio físico queno resida en la carpeta C:\Inetpub\wwwroot. Al crear un directorio virtual de esta manera, se creaautomáticamente una aplicación Web en el directorio virtual.

Para crear un directorio virtual

En el Administrador IIS, expanda el nodo equipo local (que puede estar indicado con el nombre del equipo),expanda Sitios Web y haga clic en Sitio Web predeterminado.

En el menú Acción, haga clic en Nuevo y, a continuación, haga clic en Directorio virtual.En el Asistente para crear un directorio virtual, haga clic en Siguiente.En el cuadro Alias, escriba el nombre que desea para su nueva aplicación y, a continuación, haga clic enSiguiente.En el cuadro Ruta de acceso, escriba el nombre del directorio físico que creó en los pasos preliminares deeste tutorial, C:\exampleWebApp, y, a continuación, haga clic en Siguiente.Alternativamente, puede hacer clic en el botón Examinar para desplazarse hasta su directorio.En la página Permisos de acceso, asegúrese de que están activadas las casillas de verificación Lectura yEjecutar secuencias de comandos y, a continuación, haga clic en Siguiente.Haga clic en Finalizar.Su nueva aplicación Web se crea y aparece resaltada en el Administrador IIS.

Convertir un directorio virtual existente en una aplicación Web

Además, puede crear un directorio raíz de la aplicación en un directorio existente en Inetpub\Wwwroot. IIStrata todos los directorios físicos situados bajo Inetpub\Wwwroot como directorios virtuales, pero no seconsideran aplicaciones hasta que no se realiza el procedimiento siguiente.Para marcar un directorio virtual existente en Inetpub\Wwwroot como aplicación Web mediante IISAbra el Administrador IIS y desplácese hasta el Sitio Web predeterminado, como en los procedimientosanteriores.Expanda el nodo Sitio Web predeterminado y busque el subdirectorio que desee designar como raíz deaplicación. En este ejemplo es exampleWebApp.Si el Administrador IIS ya estaba abierto al crear el directorio físico, puede que tenga que hacer clic en elbotón Actualizar del Administrador IIS para ver el nuevo subdirectorio exampleWebApp.Haga clic con el botón secundario en el directorio que desea marcar como raíz de aplicación y, a continuación,haga clic en Propiedades.


3

En la ficha Directorio, en la sección Configuración de la aplicación, haga clic en Crear.En el cuadro de texto Nombre de la aplicación, escriba el nombre de la aplicación y haga clic en Aceptar.Ahora, el directorio virtual es una raíz de aplicación.

Despliegue de aplicaciones en IIS con Visual Studio.

Debes crearte una carpeta en tu disco duro (Por ejemplo en C:\Inetpub\wwwroot\miservicoweb) con elnombre que quieras y en ella copias los archivos por ejemplo:

Global.asaxServicio.asmxWeb.configDirectorio bin

Luego te vas a los Servicios de Internet Information Server y creas un directorio virtual apuntando a esacarpeta y recuerda si tienes mas de un framework instalado poner la versión correcta y como página deinicio el nombre del servicio en mi caso Servicio.asmx

Precompilación de aplicaciones.

Características:

Precompilar un sitio web de ASP.NET ofrece las ventajas siguientes:

El tiempo de respuesta para los usuarios es más rápido, ya que las páginas y los archivos de código no tienenque compilarse la primera vez que se solicitan. Esto resulta especialmente útil en sitios grandes que seactualizan con frecuencia.

Se trata de una forma de identificar los errores en tiempo de compilación antes de que los usuarios vean unsitio.

Es posible crear una versión compilada del sitio que se puede implementar en un servidor de producción sinel código fuente.


4

Información general:

De forma predeterminada, las páginas Web ASP.NET y los archivos de código se compilan de forma dinámicala primera vez que los usuarios solicitan un recurso como, por ejemplo, una página de un sitio Web. Una vezcompiladas las páginas y los archivos de código por primera vez, los recursos de compilación se almacenanen la memoria caché. Por consiguiente, las solicitudes posteriores a la misma página serán muy eficaces.

ASP.NET también puede precompilar un sitio completo antes de ponerlo a disposición de los usuarios. ASP.NETproporciona las siguientes opciones para precompilar un sitio:

- Precompilar un sitio en contexto. Esta opción es útil para aquellos sitios donde se desea mejorar elrendimiento y realizar la comprobación de errores.

- Precompilar un sitio para implementarlo. Esta opción crea un resultado especial que se puedeimplementar en un servidor de producción.

Además, puede precompilar un sitio para que sea de sólo lectura o actualizable. En las secciones siguientesse proporcionan más detalles sobre cada opción.

Precompilación en contexto

Se puede mejorar en cierto modo el rendimiento de un sitio web si se precompila. Esto es particularmentecierto en los sitios donde se producen cambios e incorporaciones frecuentes en las páginas web ASP.NET y enlos archivos de código. En un sitio web fluido, el tiempo adicional necesario para compilar dinámicamentelas páginas nuevas y modificadas puede afectar a la calidad que percibe el usuario.

Si se precompila un sitio en contexto de forma eficaz, se realiza la misma compilación que cuando los usuariossolicitan las páginas del sitio. Por consiguiente, la principal mejora en el rendimiento consiste en que laspáginas no tienen que compilarse la primera vez que se solicitan.

Cuando se realiza la precompilación en contexto, se compilan todos los tipos de archivo de ASP.NET. (Losarchivos HTML, de gráficos y otros archivos estáticos que no son ASP.NET se dejan tal cual). El proceso deprecompilación sigue la misma lógica que utiliza ASP.NET para la compilación dinámica y tiene en cuenta lasdependencias entre los archivos. Durante la precompilación, el compilador crea ensamblados para todo elresultado ejecutable y los coloca en una carpeta especial bajo la carpeta %raízDelSistema%\Microsoft.NET\Framework\versión\Temporary ASP.NET Files. A continuación, ASP.NET atiende las solicitudes de las páginasde los ensamblados de dicha carpeta.


5

Si se vuelve a precompilar el sitio, sólo se compilarán aquellos archivos que sean nuevos o que se hayanmodificado (o aquéllos que tienen dependencias en el tipo de archivos descritos). Debido a esta optimizaciónpor parte del compilador, resulta práctico compilar el sitio incluso después de realizar actualizaciones pocorelevantes.

Precompilación para implementación

Otro uso de la precompilación de un sitio consiste en generar una versión ejecutable del sitio en cuestiónque se pueda implementar en un servidor de producción. Al precompilar para implementación, se crea unresultado en formato de diseño. El diseño contiene ensamblados, información de configuración, informaciónsobre las carpetas del sitio y archivos estáticos (como archivos HTML y gráficos).

Después de compilar el sitio, se puede implementar el diseño en un servidor de producción utilizandoherramientas como el comando Windows XCopy, FTP, la instalación de Windows, etcétera. Una vezimplementado el diseño, éste funciona como el sitio indicado y ASP.NET atiende las solicitudes de páginasdesde los ensamblados del diseño en cuestión.

Precompilar un sitio para implementación es una medida de protección del código fuente y de otra propiedadintelectual.

Se puede realizar una precompilación para su posterior implementación de dos maneras: precompilar sólopara implementación o precompilar para implementación y actualización.

Precompilar sólo para implementación

Cuando se precompila sólo para realizar una implementación, el compilador genera los ensamblados de casitodos los archivos de código fuente de ASP.NET que normalmente se compilan en tiempo de ejecución. Aquíse incluye el código de programas de páginas, archivos de clases .cs y .vb, otros archivos de código y derecursos. El compilador quita de los resultados todo el código fuente y el de marcado. En el diseño resultante,se generan archivos compilados para cada uno de los archivos .aspx (con la extensión .compiled) quecontienen punteros al ensamblado adecuado para dicha página.

Para cambiar el sitio web, incluido el diseño de las páginas, es necesario cambiar los archivos originales,recompilar el sitio e implementar de nuevo dicho diseño. La única excepción es la configuración del sitio.Puede realizar cambios en el archivo Web.config en el servidor de producción sin tener que volver a compilarel sitio.

Esta opción proporciona el mayor grado de protección para las páginas web ASP.NET y el mejor rendimientoal iniciar el sistema.


6

Precompilar para implementación y actualización

Cuando se precompila para implementación y actualización, el compilador genera ensamblados de todo elcódigo fuente (excepto del código de las páginas de un solo archivo) y de otros archivos que normalmentegeneran ensamblados, como los de recursos. El compilador convierte archivos .aspx en archivos únicos queutilizan el modelo de código subyacente compilado y los copian en el diseño.Esta opción permite realizar cambios limitados en las páginas web ASP.NET de un sitio después de compilarlas.Por ejemplo, se puede cambiar la organización de los controles, colores, fuentes y otros aspectosrelacionados con el aspecto de las páginas. También se pueden agregar controles, siempre que no requierancontroladores de eventos u otro código.

Cuando el sitio se ejecuta por primera vez, ASP.NET realiza otra compilación para crear el resultado a partirdel marcado.

Matriz de decisión de precompilación

Usa la tabla siguiente para decidir cuál es el modelo de compilación que debe utilizar. Algunas de las opcionesenumeradas en la tabla se describen más adelante en este tema.


7


8

Realizar precompilación

Al precompilar un sitio web se aplica una restricción de código a los sitios que se van a compilar con laprotección de código fuente habilitada. Una clase de página base (una clase de código subyacente) puedehacer referencia a la clase de página (archivo .aspx) y a los miembros de la clase de página asociadosutilizando un nombre de clase completo. Sin embargo, esta clase de referencia no funcionará al precompilarel sitio con la protección de código fuente habilitada. Esto se debe a que la clase de página base del archivode código subyacente no se encuentra en el mismo ensamblado que la clase de página derivada de la página.aspx.

Compilación predeterminadaNo es necesario manualmente. De forma predeterminada, ASP.NET compila la aplicación web la primera vezque un explorador web solicite una página de la aplicación. Si realiza un cambio en un archivo de laaplicación, la próxima vez que se solicite una página el tiempo de ejecución de ASP.NET determina lasdependencias del archivo modificado. Vuelve a compilar sólo los archivos afectados por el cambio.

Las ventajas de la compilación predeterminada son las siguientes:

1. Es fácil de utilizar. El compilador de ASP.NET hace todo el trabajo.2. Es el mejor modelo de compilación durante el desarrollo cuando los pasos adicionales requeridos

para precompilar un sitio web ralentizan el proceso de desarrollo.

Las desventajas de la compilación predeterminada son las siguientes:

1. Pueda causar importantes retrasos cuando se solicita por primera vez el sitio Web.2. Requiere el almacenamiento de los archivos de código fuente en el servidor de producción.3. Hace que el código fuente y el código de la interfaz de usuario estén disponibles para cualquier

usuario con acceso al sistema de archivos del directorio de sitios Web en el servidor.

Cuándo utilizar la compilación predeterminada

Utilice la compilación predeterminada en los siguientes casos:

1. Al desarrollar y probar un sitio Web.2. Para los sitios web con información principalmente estática.3. Para los sitios Web que no cambian con frecuencia.

Si no le preocupa almacenar los archivos de código fuente en el servidor de producción.

Compilación en contexto

Puede precompilar un sitio que ya está en un servidor de producción. Esto se denomina compilación encontexto. Si realiza un cambio en un archivo de la aplicación, puede volver a compilar el archivo afectadocon la herramienta de compilación de ASP.NET.

Los archivos afectados también se volverán a compilar la próxima vez que se solicite una página de laaplicación.

Las ventajas de utilizar la compilación en contexto son las siguientes:

1. Se reduce el tiempo de respuesta a la primera solicitud desde el sitio Web. 2. No se necesita dar ningún paso de implementación especial; la aplicación se compila exactamente

igual que cuando se solicita una página del sitio.

Las desventajas de utilizar la compilación en contexto son las siguientes:

1. Todo el código fuente de la aplicación debe almacenarse en el servidor de producción.2. Hace que el código fuente y el código de la interfaz de usuario estén disponibles para cualquier

usuario con acceso al directorio de sitios Web.

Cuándo utilizar la compilación en contexto

Utilice la compilación en contexto en los siguientes casos: Se realizan cambios frecuentes en las páginas del sitio web.No le preocupa almacenar los archivos de código fuente en el servidor de producción.Desea mejorar el tiempo de respuesta de las primeras solicitudes de página.

Precompilar con una interfaz de usuario actualizable

Utilizando el modificador -u de la herramienta de compilación de ASP.NET puede compilar el código fuente(.cs, archivos .vb y archivos .resource) a una DLL. Puede dejar el marcado de la interfaz de usuario de losarchivos .aspx disponible para actualizar. Una vez implementado el sitio web en un servidor de producción,se pueden realizar cambios en el código .aspx sin tener que volver a compilar todo el sitio web.


9

Las ventajas de precompilar un sitio web con una interfaz de usuario actualizable son las siguientes:

1. Se reduce el tiempo de respuesta a la primera solicitud desde el sitio Web.

2. Los diseñadores de la interfaz de usuario pueden modificar la apariencia y el comportamiento deun sitio web sin tener que volver a compilar todo el sitio web.

Es una medida de protección de la propiedad intelectual en el código fuente de la aplicación. Se protege dela observación casual por cualquiera que tenga acceso al directorio de sitios web.Las desventajas de precompilar un sitio web con una interfaz de usuario actualizable son las siguientes:

1. Requiere un paso de compilación independiente antes de la implementación en servidores deproducción.

2. La propiedad intelectual de la interfaz de usuario (archivos .aspx) de la aplicación está disponiblepara cualquier usuario con acceso al directorio de sitios web.

Varias páginas no pueden hacer referencia a la misma clase CodeFile, que es el archivo de código asociadopara una página que utiliza el modelo de código subyacente.

Cuándo precompilar con una interfaz de usuario actualizable

Precompile una aplicación para que tenga una interfaz de usuario actualizable en los siguientes casos:

Los diseñadores de la interfaz de usuario trabajan de manera independiente de los desarrolladores del códigofuente.

El código fuente del programa contiene propiedad intelectual que desea proteger de la observación casual.No desea almacenar el código fuente del programa en el servidor de producción.

Precompilar con una interfaz de usuario no actualizable

La herramienta de compilación de ASP.NET puede compilar todo el código fuente de una aplicación en DLLque se implementan en el directorio Bin de la aplicación. Se incluyen los archivos de la interfaz de usuario,como .aspx y .ascx.


10

Las ventajas de precompilar con una interfaz de usuario no actualizable son las siguientes:

1. Se reduce el tiempo de respuesta a la primera solicitud desde el sitio Web.

Es una medida de protección de la propiedad intelectual en el código fuente de la aplicación y en el códigode la interfaz de usuario. Se protege de la observación casual por cualquiera que tenga acceso al directoriode sitios web.

Las desventajas de precompilar con una interfaz de usuario no actualizable son las siguientes:

1. Requiere un paso de compilación independiente antes de la implementación en servidores deproducción.

Incluso los pequeños cambios realizados en la interfaz de usuario de la aplicación requieren que se vuelva acompilar todo el sitio web.

Cuándo precompilar con una interfaz de usuario no actualizable

Precompile el sitio web para que tenga una interfaz de usuario no actualizable en los siguientes casos:

- El código de la interfaz de usuario contiene propiedad intelectual que desea proteger de laobservación casual.

- No tiene que cambiar la interfaz de usuario con frecuencia.- Sólo desea tener archivos DLL compilados en el servidor de producción.

Precompilar en ensamblados de nombre fijo

La herramienta de compilación de ASP.NET utiliza nombres aleatorios para los ensamblados que se generandurante la compilación. El nombre del ensamblado cambia cada vez que se vuelve a compilar la aplicación. Dado que los nombres de ensamblado cambian, es preciso volver a implementar toda la aplicación parareparar un ensamblado. Sin embargo, utilizando el modificador -fixednames de la herramienta de compilaciónde ASP.NET, se puede crear un ensamblado para cada página de la aplicación. El nombre del ensamblado nocambiará en compilaciones posteriores. Por consiguiente, puede crear actualizaciones Service Release parala aplicación que reemplacen sólo los ensamblados cambiados.

Dado que el modificador -fixednames crea un ensamblado individual para cada página, se debe limitar elnúmero de páginas de la aplicación.


11

Las ventajas de precompilar en ensamblados de nombre fijo son las siguientes:

1. El nombre de los ensamblados individuales no cambia de una compilación a otra. Esto le permitereemplazar ensamblados concretos sin volver a implementar toda la aplicación.

2. Las actualizaciones secundarias de la aplicación pueden ser más específicas.

Las desventajas de precompilar en ensamblados de nombre fijo son las siguientes:

1. Se crea un ensamblado para cada página en la aplicación. Esto puede crear muchos ensambladosen el caso de sitios que tengan muchas páginas.

Cuándo precompilar en ensamblados de nombre fijo

Precompile el sitio web en ensamblados de nombre fijo en los siguientes casos:Necesita reparar aplicaciones web sin tener que reemplazar toda la aplicación.

Precompilar en ensamblados firmadosSe puede usar la herramienta de compilación de ASP.NET para crear ensamblados de nombre seguro que sepuedan implementar en la Caché de ensamblados global (GAC) o el directorio Bin de la aplicación. Si seutiliza un ensamblado firmado, es más difícil que usuarios malintencionados reemplacen los ensamblados dela aplicación con código malintencionado.

Las ventajas de precompilar en ensamblados firmados son las siguientes:

1. Los ensamblados firmados aumentan la seguridad de la aplicación ya que es más difícil que losensamblados sean reemplazados por código malintencionado.

Las desventajas de precompilar en ensamblados firmados son las siguientes:

1. La administración de claves en los entornos de desarrollo compartidos puede ser compleja.

El atributo AllowPartiallyTrustedCallersAttribute de los ensamblados debe ser invocado por el motor entiempo de ejecución de ASP.NET.


12

Cuándo precompilar en ensamblados firmados

Precompile el sitio web en ensamblados firmados en los siguientes casos:

Los usuarios tienen acceso al directorio de la aplicación o al GAC, y pueden reemplazar los ensamblados dela aplicación.

Desea limitar la capacidad de otros usuarios para reemplazar los ensamblados generados por el código de laaplicación.

Escribir los resultados de la precompilación

Cuando finaliza el proceso de precompilación, el resultado se escribe en una carpeta especificada. Puedeescribir el resultado en cualquier carpeta a la que tenga acceso en el sistema de archivos, mediante FTP (FileTransfer Protocol, Protocolo de transferencia de archivos) o HTTP. Debe tener los permisos adecuados parapoder escribir en el sitio de destino.

Puede especificar una carpeta de destino en un servidor de ensayo o de producción, o puede escribir elresultado en una carpeta del equipo local. Si especifica una carpeta en un servidor de producción, puedeprecompilar e implementar en un solo paso. Si escribe el resultado en una carpeta que no forma parte delsitio web, puede copiar el resultado en el servidor en un paso independiente.

El resultado del proceso de compilación incluye los ensamblados compilados de código o páginas. Si elige laopción que permite que el sitio precompilado se actualice, las clases de código subyacente de los archivos.aspx, .asmx y .ashx se compilan en ensamblados. Sin embargo, los propios archivos .aspx, .asmx y .ashx secopian tal cual en la carpeta de destino por lo que puede cambiar su diseño después de implementar el sitio.Por lo que respecta a sitios que se pueden actualizar, el código de páginas únicas no se compila en ningúnensamblado. En su lugar, se implementa como código fuente.

No se compilan los archivos estáticos. En su lugar, se copian tal cual en la carpeta de salida.

Los archivos estáticos incluyen gráficos, archivos .htm o .html, de texto, etc.

Si se produce un error durante la precompilación, se informa de él en las ventanas Resultados y Lista deerrores. Los errores durante la precompilación evitarán que se compile y se publique el sitio.


13


14

Control de archivos durante la compilación previa de ASP.NET

Al precompilar un sitio para implementación, ASP.NET crea un diseño, es decir, una estructura que contienelos resultados del compilador. En esta sección se describe cómo trabajar con los archivos durante laprecompilación, así como la estructura del diseño y su contenido.

Es posible precompilar tanto el código fuente (cualquier archivo que genera un ensamblado, incluido elcódigo del programa y los recursos) como el marcado (archivos .aspx), o sólo el código fuente.Archivos compilados

El proceso de precompilación hace acciones en distintos archivos en una aplicación Web ASP.NET. Los archivosse tratan de manera diferente dependiendo de si la aplicación se precompila solo para implementación o sise precompila para implementación y actualización.

En la siguiente tabla se describen los diferentes tipos de archivo y las acciones que se realizan en ellos si laaplicación sólo se precompila para implementación.


15

En la siguiente tabla se describen los diferentes tipos de archivo y las acciones que se realizan con los mismossi la aplicación se precompila para la implementación y la actualización.


16

Archivos .compiled

En el caso de los archivos ejecutables de una aplicación web ASP.NET, el compilador agrega la extensión.compiled al nombre de los ensamblados y archivos. El compilador genera el nombre de ensamblado. Elarchivo .compiled no contiene código ejecutable. Por el contrario, sólo contiene la información que ASP.NETnecesita para encontrar el ensamblado adecuado.

Tras implementar la aplicación precompilada, ASP.NET utiliza los ensamblados de la carpeta Bin para procesarsolicitudes. El resultado de precompilación incluye archivos .aspx o .asmx como marcadores de posición paralas páginas. Los archivos de marcador no contienen código. Sólo existen para invocar ASP.NET para unasolicitud de página determinada. Los archivos de marcador de posición también permiten establecer lospermisos de archivo para restringir el acceso a las páginas.


17

Actualizar sitios web precompilados

Tras desarrollar un sitio web precompilado, se pueden realizar algunos cambios en los archivos del sitio, conciertas limitaciones. En la tabla siguiente se describe el efecto de algunos tipos de cambios.

Cómo precompilar sitios Web ASP.NET para la implementación

En el momento de precompilar un sitio Web ASP.NET para la implementación, se crea un diseño que contieneensamblados y otro tipo de información que se puede copiar a continuación en un servidor de producción.Un sitio Web que se precompila para la implementación permite crear una versión compilada del sitio quese puede implementar en un servidor de producción sin código fuente.

Se puede optar por precompilar código y páginas .aspx, o bien, sólo código. Si se precompila sólo el código,se puede actualizar la interfaz de usuario del sitio sin tener que volver a compilar el sitio completo.

Los procedimientos de este tema utilizan los modificadores y parámetros de la herramienta Compilación deASP.NET (Aspnet_compiler.exe).

Para precompilar un sitio Web ASP.NET para implementación

Abre una ventana de comandos y vaya a la carpeta que contiene .NET Framework.

.NET Framework está instalado en la ubicación siguiente:

%windir%\Microsoft.NET\Framework\version

Ejecuta el comando aspnet_compiler escribiendo lo que figura a continuación en el símbolo del sistema yespecificando el origen como una ruta de acceso virtual o física así como la carpeta de destino del sitio Webcompilado.

aspnet_compiler -v virtualPathtargetPath

Si el sitio Web no es una aplicación de Servicios de Internet Information Server (IIS) y, por lo tanto, no tieneninguna entrada en la metabase de IIS, utilice el siguiente valor para el modificador -v.

aspnet_compiler -p physicalOrRelativePath -v / targetPath

En este caso, el parámetro physicalOrRelativePath hace referencia a la ruta de acceso completa del directorioen el que están ubicados los archivos del sitio Web, o bien, una ruta de acceso relativa al directorio actual.El operador . (punto) se permite en el parámetro physicalOrRelativePath.


18

El modificador -v especifica la raíz que el compilador utilizará para resolver las referencias a la raíz de laaplicación, por ejemplo, con el operador ~ (tilde). Cuando se especifica el valor de / para el modificador -v, el compilador resolverá las rutas de acceso utilizando la ruta de acceso física como raíz.

El parámetro targetPath es una ruta de acceso física al directorio de destino.

Para precompilar un sitio Web ASP.NET para la implementación y actualización

Abra una ventana de comandos y vaya a la carpeta que contiene .NET Framework.

.NET Framework está instalado en la ubicación siguiente:

%windir%\Microsoft.NET\Framework\version

Ejecuta el comando aspnet_compiler escribiendo lo que figura a continuación en el símbolo del sistema yespecificando el origen como una ruta de acceso virtual o física, la carpeta de destino del sitio Web compiladoy el modificador -u que indica que desea compilar el sitio para la implementación y actualización.aspnet_compiler -p physicalOrRelativePath -v / targetPath -u


19

En este caso debes implementar un procedimiento que valide si un usuario es válido.

Conviene destacar:

- Con IsValid comprobamos si el formulario está correcto, esto es opcional.- Ccon el método Autenticate de la clase FormsAuthentication, hacemos que se localice en el

web.config el nombre de usuario y la contraseña introducidas. Devolverá un true o false si loencuentra o no en la sección credentials.

- En el caso de que la respuesta sea errónea, pintamos el correspondiente mensaje de error enla etiqueta reservada para esto.

- Si hemos acertado con el usuario y la contraseña entra en juego el método RedirectFromLogin-Page, al que le pasamos el usuario y el valor del check para que en el futuro nos pregunte o nopor nuestra identificación. Este nos devolverá a la url que hemos intentado acceder dentro denuestro directorio privado antes de que se nos mostrara la página de login.

CONFIGURACIÓN Y DESPLIEGUE DE APLICACIONES WEB CASO PRÁCTICO

1


En este caso, tendrás que desarrollar una interfaz HTML en la que tendremos un textarea y un botón de“Mostrar contenido” de un fichero de texto que estará ubicado en el servidor web. Todo a través de unapágina ASP .NET (aspx).

APLICACIONES WEB CON ASP.NET

1


Módulo_13_Configuración y despliegue de aplicaciones WEB

Documents

Transcript of Módulo_13_Configuración y despliegue de aplicaciones WEB