Desarrollo de aplicaciones para Internet

En el clienteEn el servidorEvolución de las aplicaciones web

Actualmente se observa una tendencia a utilizar los estándares de Internet (más concretamente, la web) para desarrollar aplicaciones de gestión en medianas y grandes empresas. En este tipo de aplicaciones se utiliza software que se descarga de un servidor web, por lo que se facilitan las tareas de mantenimiento y actualización en grandes sistemas.

En el cliente

En principio, el software se puede desarrollar de forma que todo el trabajo lo realice el servidor web y el usuario final sólo necesite un navegador web, si bien esta opción no resulta demasiado atractiva por las limitaciones de los formularios HTML. Debido a estas limitaciones, han surgido numerosas alternativas que permiten ejecutar código en el cliente: DHTML/JavaScript, COM (controles ActiveX), applets Java, plug-ins específicos... Con estas tecnologías se mejora la escalabilidad de las aplicaciones (ya que se realiza menos trabajo en el servidor) y se mejora tanto la productividad como la satisfacción del usuario final (al emplear interfaces más depuradas), además de conseguir aplicaciones muy atractivas de cara al mercado (animaciones, presentaciones Flash...).

HTML dinámico (DHTML): Se escriben macros (scripts) que se incrustan en los ficheros HTML. Usualmente se utiliza Javascript por cuestiones de portabilidad, si bien navegadores como el Internet Explorer también permiten otros lenguajes como VBScript. En HTML dinámico, cada etiqueta HTML se convierte en un objeto con sus propiedades y eventos asociados. Los scripts han de proporcionarle al navegador el código correspondiente a la respuesta prevista por el programador para los distintos eventos que se pueden producir.

ActiveX: Disponible únicamente en el Internet Explorer (al menos, en principio), es una tecnología basada en COM. Permite desarrollar código eficiente, si bien su utilización se suele limitar a intranets.

Applets: Son aplicaciones escritas en Java en las que se distribuye el código intermedio correspondiente a la máquina virtual Java (bytecodes). Tienen la ventaja de ser portables (a cualquier plataforma que disponga de un interprete de bytecodes) y destacan por su seguridad (cada aplicación se ejecuta en un espacio independiente [sandbox] que, en principio, no puede acceder al hardware de la máquina del cliente). Algunos problemas de rendimiento (y, sobre todo, cuestiones de mercado) han limitado su utilización.

En el servidor

También se han desarrollado numerosas alternativas que permiten desarrollar aplicaciones web desde el punto de vista del servidor. Cuando el software se ejecuta en el servidor, éste suele recibir datos provenientes de URLs, formularios HTML, cookies y cabeceras HTTP. Una vez procesados estos datos (accediendo, posiblemente, a bases de datos, ficheros, mainframes, etc.), se genera dinámicamente una respuesta personalizada en HTML para cada cliente concreto. Entre las ventajas del software desarrollado de esta forma destacan su accesibilidad (desde cualquier punto de Internet), su mantenimiento (no hay que distribuir el código de las aplicaciones ni sus actualizaciones), su seguridad (el código no puede manipularlo el usuario) y su escalabilidad (utilizando arquitecturas multicapa).

Tecnologías

CGI (Common Gateway Interface) ISAPI (Internet Server API) @ Microsoft IIS NSAPI (Netscape Server API) ASP (Active Server Pages) JSP (Java Server Pages) & servlets PHP (Personal Home Page)

ColdFusion (CFM)

...

Ejemplo: ASP y JSP

Las páginas ASP permiten crear aplicaciones web fácilmente utilizando usualmente un lenguaje como VBScript. Una página ASP contiene HTML estático intercalado con scripts que se encargan de generar HTML de forma dinámica. JSP funciona de forma análoga, si bien utiliza el lenguaje de programación Java. Tanto ASP como JSP gozan de gran aceptación a pesar de que no fuerzan uno de los principios básicos de diseño de software: la separación entre la interfaz de una aplicación y su lógica interna.

Evolución de las aplicaciones web

HTML estàtico

Crear un sitio web es bastante fácil. Sólo se necesita un servidor web que atienda peticiones HTTP y un conjunto de ficheros HTML con información. El inconveniente de los ficheros HTML es que son estáticos y generalmente nos interesa algo más que mostrar siempre la misma información (y tener que actualizar a mano periódicamente los ficheros HTML no parece una gran idea).

Aplicaciones web

La creación de aplicaciones web requieren que exista software ejecutándose en el servidor que genere automáticamente los ficheros HTML que se visualizan en el navegador del cliente. La comunicación entre el cliente y el servidor se realiza a través de HTTP, un protocolo simple en el que se establece una conexión TCP independiente para cada par solicitud-respuesta. Esto implica que el entorno de programación que empleemos debería facilitarnos el mantenimiento de sesiones de usuario.

En el caso de CGI escribimos programas estándar en línea de comandos que aceptan una serie de parámetros y generan un fichero HTML en su canal de salida estándar (stdout en el caso de C), lo que no facilita en nada nuestra tarea. En IIS, el servidor web de Microsoft, as DLLs de ISAPI (Internet Services Application Programming Interface) mejoran el rendimiento de los CGI y poco más. Las tecnologías que nos permiten escribir macros (tipo ASP o JSP) resultan algo más cómodas para el programador, que puede centrarse en la lógica de su aplicación sin tener que preocuparse en exceso de los detalles de HTTP y HTML, si bien el diseño de las aplicaciones resultantes no suele ser demasiado elegante (pues mezcla la interfaz de usuario con la lógica de la aplicación).

En cualquier caso, el navegador del cliente es independiente de la tecnología que se utilice en el servidor, ya que a él sólo le llega una página HTML estándar (que habrá sido generada dinámicamente en el servidor) y se limita a mostrarla tal cual.

Servicios web

Los servicios web, básicamente, establecen un lenguaje común mediante el cual distintos sistemas puedan comunicarse entre sí y, de esta forma, construir sistemas distribuidos heterogéneos:

Aplicaciones Web con ASP.NET

ASP: Active Server PagesASP.NET: Aplicaciones web en la plataforma .NET

ASP: Active Server Pages

ASP permite desarrollar aplicaciones para Internet que se ejecutan en el servidor. Básicamente, desarrollar páginas ASP consiste en intercalar documentos HTML estáticos y macros dinámicas, mezclando la interfaz con la lógica de las aplicaciones, lo que, por cierto, no suele ser demasiado recomendable.

Una página ASP no es más que un fichero HTML con extensión .asp (.aspx en el caso de ASP.NET). Cuando alguien accede a la página, en el servidor procesa el código que aparezca en la página y devuelve el resultado al navegador del cliene (como una página web más), de ahí el AS de ASP.

La tecnología ASP, igual que JSP en Java y otras muchas alternativas, incluye un conjunto de objetos intrínsecos que proporcionan distintos servicios útiles en el desarrollo de aplicaciones web (Request, Response, Server, Application, Session), además de facilidades para acceder a componentes COM (p.ej. uso de ADO [ActiveX Data Objects] para acceder a bases de datos). Las páginas ASP se pueden escribir utilizando distintos lenguajes interpretados (usualmente una

variante de Visual Basic conocida como VBScript), por lo que basta con escribir la página, guardarla y acceder a ella a través del Internet Information Server (IIS, el servidor HTTP de Microsoft), sin tener que compilarla previamente.

El siguiente ejemplo muestra cómo se pueden crear páginas ASP que generen su contenido dinámicamente:

<html><head><title>Hora.asp</title></head><body><h2> Hora actual </h2><% Response.Write(Now()) %></body></html>

El código que aparece entre las etiquetas <% y %> se interpreta en el servidor. Response.Write sirve para escribir algo en la página HTML de salida y Now() es una función que devuelve la fecha y hora actuales.

El ejemplo anterior podemos modificarlo un poco para que el usuario pueda visualizar la hora actual en el momento en que le interese, no simplemente cuando carga la página por primera vez:

<html><head><title>Hora.Request.asp</title></head><body><form method="post"><input type="submit" id=button name=buttonvalue="Pulse el botón para consultar la hora" /><%if (Request.Form("button") <> "") thenResponse.Write "<p>La hora actual es " & Now()end if%></form></body></html>

En esta ocasión hemos utiizado el objeto Request que nos permite aceptar datos de entrada en nuestra página ASP. Para comprobar los ejemplos anteriores funcionan, sólo hay que guardar los ficheros ASP correspondientes en algún sitio que cuelque del directorio wwwroot del IIS y acceder a él desde el navegador utilizando una URL de la forma http://localhost/....

Las versiones de ASP anteriores a ASP.NET (ASP Clásico, como algunos las llaman) requieren escribir bastante código, como por el ejemplo el necesario para mantener el estado de la página. Este código, además, es poco legible y difícil de mantener al estar mezclado con el HTML de la interfaz gráfica. En ASP, el fragmento de código ha de colocarse en el sitio donde queremos que su salida aparezca, haciendo imposible separar el interfaz de la lógica de la aplicación. Este hecho dificulta la reutilización de código y complica el soporte para múltiples navegadores. Por otro lado, el ASP Clásico presenta algunos inconvenientes a la hora de implantar sistemas reales (configuración, eficiencia, depuración...), muchos de los cuales provienen de las limitaciones de los lenguajes interpretados que se utilizan para escribir las macros ASP.

Las limitaciones e inconvenientes mencionados dieron lugar a una serie de cambios en ASP.NET. ASP.NET, por tanto, no es completamente compatible con ASP, si bien la mayor parte de las páginas ASP sólo requieren pequeños cambios para pasarlas a ASP.NET. De hecho, el primero de los ejemplos funciona correctamente como página ASP.NET (cambiándole la extensión a .aspx) y el segundo funciona si tenemos en cuenta que en Visual Basic .NET los paréntesis son obligatorios en las llamadas a métodos.

ASP.NET: Aplicaciones web en la plataforma .NET

ASP.NET es el nombre con el que se conoce la parte de la plataforma .NET que permite el desarrollo y ejecución tanto de aplicaciones web como de servicios web. Igual que sucedía en ASP, ASP.NET se ejecuta en el servidor. En ASP.NET, no obstante, las aplicaciones web se suelen desarrollar utilizando formularios web, que están diseñados para hacer la creación de aplicaciones web tan sencilla como la programación en Visual Basic (.NET, claro está).

Para hacernos una idea de cómo es ASP.NET, retomemos el ejemplo de la sección anterior, que en ASP.NET queda como sigue si empleamos el lenguaje de programación C#:

<%@ Page language="c#" %><html><head><title>Hora.aspx</title></head><script runat="server">public void Button_Click (object sender, System.EventArgs e)

{LabelHora.Text = "La hora actual es " + DateTime.Now;}</script><body><form method="post" runat="server"><asp:Button onclick="Button_Click" runat="server"Text="Pulse el botón para consultar la hora"/><p><asp:Label id=LabelHora runat="server" /></form></body></html>

Para probar el ejemplo anterior sólo tenemos que guardar la página con la extensión .aspx y acceder a ella a través del IIS. Dicho ejemplo ilustra algunas de las características más relevantes de ASP.NET.

ASP.NET está construido sobre la plataforma .NET y el Internet Information Server (IIS), el servidor web de Microsoft:

La programación en ASP.NET está basada en el uso de controles y eventos (como Visual Basic), no en aceptar datos de entrada y generar la salida en HTML (como ASP), lo que le proporciona un mayor nivel de abstracción, requiere menos código y permite crear aplicaciones más modulares, legibles y mantenibles.

El código se ejecuta en el servidor web en función de los manejadores de eventos que definamos para controles y páginas. Los controles derivan todos de la clase System.Web.UI.Control y la página web en sí también es un objeto (derivado de System.Web.UI.Page, que a su vez deriva de System.Web.UI.Control). ASP.NET se encarga de garantizar la compatibilidad de los controles con los distintos navegadores que pueda utilizar el usuario.

Además, ASP.NET permite dos estilos para la creación de páginas ASP.NET:

Incluir tanto controles como código en un fichero .aspx, como hicimos en el ejemplo (a pesar de que esto nos impide aprovechar muchas de las ventajas de ASP.NET frente a ASP).

Mantener los controles en un fichero .aspx y dejar el código aparte (code-behind page), lo que permite separar físicamente la interfaz de usuario del código de la aplicación:

En la página ASP.NET (fichero HoraWebForm.aspx):<%@ Page language="c#" Codebehind="HoraWebForm.aspx.cs" Inherits="HoraWeb.WebForm" %><html><head><title>Hora.aspx</title></head></script><body><form method="post" runat="server"><asp:Button id="ButtonHora" runat="server"Text="Pulse el botón para consultar la hora" /><p><asp:Label id="LabelHora" runat="server" /></form></body></html>

En un fichero de código aparte (HoraWebForm.aspx.cs):namespace HoraWeb{public class WebForm : System.Web.UI.Page{protected System.Web.UI.WebControls.Button ButtonHora;protected System.Web.UI.WebControls.Label LabelHora;

override protected void OnInit(EventArgs e){this.ButtonHora.Click += new System.EventHandler(this.ButtonHora_Click);base.OnInit(e);}

private void ButtonHora_Click(object sender, System.EventArgs e){LabelHora.Text = "La hora actual es "+DateTime.Now;}}}

Como es lógico, lo anterior lo haremos con la ayuda del entorno de desarrollo, que se encargará de rellenar muchos huecos de forma automática para que nos podamos centrar en la

funcionalidad de nuestra aplicación...

Formularios web

FormulariosControlesFuncionamiento de las páginas ASP.NET

Formularios

Visual Studio .NET proporciona un entorno de programación visual orientado a objetos mediante el cual podemos crear aplicaciones web utilizando componentes ASP.NET (por derivación y por composición). Esto nos permite desarrollar aplicaciones web prestando poca atención al HTML en sí, ya que este no es más que el mecanismo a través del cual los distintos controles de nuestra interfaz se presentan al usuario final de nuestras aplicaciones.

ASP.NET, en realidad, es una DLL ISAPI que encapsula al CLR (Common Language Runtime) de la plataforma .NET y permite utilizar ésta en el desarrollo de aplicaciones web:

Las aplicaciones web ASP.NET están formadas por formularios web, que usualmente se dividen un fichero .ASPX en el que se especifica la interfaz y un fichero de código en el que se implementa la lógica de la aplicación. Para poder acceder a la aplicación web, basta con poner esos dos ficheros en algún lugar accesible a través del IIS (el directorio raíz wwwroot, por ejemplo). Al acceder a la página .ASPX, el código se compila automáticamente y se genera un assembly en la caché del CLR. Si el texto de la página cambia, el código se recompila automáticamente. Si no cambia, las solicitudes que se reciban a continuación utilizarán directamente la versión compilada que se halla en la caché, con lo que se mejora notablemente la eficiencia de las aplicaciones web respecto a versiones previas de ASP.

Fichero .aspx<% @Page Language="C#" Inherits="TodayPage" Src="Today.cs" %>

<html><body><h1 align="center">Hoy es <% OutputDay(); %></h1></body></html>

Fichero .csusing System;using System.Web.UI;

public class TodayPage:Page{protected void OutputDay()

{Response.Write(DateTime.Now.ToString("D"));}}

Código fuente

En el fichero .ASPX se puede incluir código, si bien lo habitual será utilizar controles predefinidos. Técnicamente, la página .ASPX hereda de la clase definida en el fichero de código, la cual a su vez hereda de System.Web.UI.Page. De forma que basta con definir los métodos de esta clase como protected para poder acceder a ellos desde el fichero .ASPX.

Controles

Las aplicaciones web usualmente emplean controles predefinidos en la biblioteca de clases de la plataforma .NET, que proporcionan un modelo orientado a objetos de los formularios web. Los controles se indican en el fichero .ASPX utilizando etiquetas de la forma <asp:... /> y se programa la lógica de la aplicación especificando la respuesta de nuestro interfaz a los distintos eventos que puedan producirse (exactamente igual que en cualquier entorno de programación visual). El servidor web se encargará de interpretar las etiquetas correspondientes a los controles ASP.NET para visualizarlos correctamente en el navegador del usuario, generando para ello el código HTML que resulte más apropiado.

Aparte de proporcionar un modelo orientado a objetos de la aplicación que evita el código "spaghetti" típico de ASP, los controles web proporcionan compatibilidad automática con distintos tipos de navegadores (aprovechando la funcionaliad de los navegadores modernos, como JavaScript o HTML dinámico, sin dejar de funcionar en navegadores más antiguos, los que se limitan a soportar HTML 3.2).

Existen tres tipos de controles ASP.NET: controles HTML (que representan etiquetas HTML tradicionales), controles web (los controles asociados a las etiquetas ASP.NET) y controles de validación (que permiten validar entradas de una forma cómoda, aunque no siempre resulte la más adecuada).

Controles HTML

Las etiquetas HTML estándar, por defecto, se tratan como texto en el servidor y se envían tal cual al cliente. Para hacerlas programables hay que añadirles un atributo runat="server". En el siguiente ejemplo podemos ver cómo podemos hacer que un enlace HTML (control HtmlAnchor) apunte dinámicamente a la URL que nos convenga: sólo tenemos que establecer un valor adecuado para su propiedad HRef en el código asociado a alguno de los eventos de la página ASP.NET:

En la página ASP.NET:<html>...<body><form id="HTMLControl" method="post" runat="server"><a id="enlace" runat="server">¡Visite nuestra página!</a></form></body><html>

En el fichero de código que hay detrás:public class HTMLControl : System.Web.UI.Page{protected System.Web.UI.HtmlControls.HtmlAnchor enlace;

private void Page_Load(object sender, System.EventArgs e){enlace.HRef = "http://elvex.ugr.es/";}

override protected void OnInit(EventArgs e){this.Load += new System.EventHandler(this.Page_Load);base.OnInit(e);}}

En Visual Studio .NET, para poder utilizar un control HTML en el servidor sólo tenemos que seleccionar la opción "Ejecutar como control del servidor" en el menú contextual asociado a la etiqueta HTML en el diseñador de formularios web. Esto hace que se añada la declaración correspondiente a la clase que define nuestro formulario, con lo cual ya podemos programar el comportamiento del control HTML.

Código fuente

IMPORTANTE: Todos los controles en una página ASP.NET deben estar dentro de una etiqueta <form> con el atributo runat="server". Además, ASP.NET requiere que todos los elementos HTML estén correctamente anidados y cerrados (como XML).

Control HTML

Etiqueta HTML

Descripción

HtmlAnchor <a> Enlace

HtmlButton <button> Botón

HtmlForm <form> Formulario

HtmlGenericCualquier elemento HTML no cubierto por un control HTML específico

HtmlImage <image> Imagen

HtmlInput...<input type="...">

Distintos tipos de entradas en un formulario HTML: botones ("button", "submit" y "reset"), texto ("text" y "password"), opciones ("checkbox" y "radio"), imágenes ("image"), ficheros ("file") y entradas ocultas ("hidden").

HtmlSelect <select>

HtmlTable...<table> <tr> <td>

Tablas, filas y celdas

HtmlTextArea <textarea>

Controles web

Los controles web encapsulan las etiquetas ASP.NET y, como es lógico, requieren el atributo runat="server" para funcionar. La sintaxis de las etiquetas ASP.NET es la siguiente:

<asp:control id="identificador" runat="server" />

donde control especifica el tipo de control web (etiquetas, botones, listas, etc.) e identificador especifica el identificador que le asociamos a la variable mediante la cual accedemos al control.

Creamos una aplicación web ASP.NET con un formulario web al que denominamos WebControl.aspx. A continuación, añadimos un botón usando el control Button que aparece en la sección "Web Forms" del "Cuadro de herramientas". Esto da lugar a algo similar a lo siguiente en la página ASP.NET:...<form id="WebControl" method="post" runat="server"><asp:Button id="Button" runat="server" Text="Pulse el botón"></asp:Button></form>...

Haciendo doble click sobre el botón podemos especificar la respuesta de este control al evento que se produce al pulsar el botón:private void Button_Click(object sender, System.EventArgs e){Button.Text = "Ha pulsado el botón";}

Código fuente

Como se puede comprobar, el desarrollo de aplicaciones web con controles ASP.NET es completamente análogo al desarrollo de aplicaciones Windows. Sólo tenemos que seleccionar los controles adecuados para nuestra interfaz e implementar la respuesta de nuestra aplicación a los eventos que deseemos controlar.

Control Descripción

AdRotatorMuestra una secuencia de imágenes (p.ej. banners)

Button Botón estándar

Calendar Calendario mensual

CheckBox Check box (como en los formularios Windows)

CheckBoxList Grupo de check boxes

DataGrid Rejilla de datos

DataListMuestra una lista utilizando plantillas (templates)

DropDownList Lista desplegable

HyperLink Enlace

Image Imagen

ImageButton Botón dibujado con una imagen

Label Etiqueta (texto estático)

LinkButton Botón con forma de enlace

ListBox Lista (como en los formularios Windows)

Literal Texto estático (similar a Label)

PanelContenedor en el que se pueden colocar otros controles

PlaceHolderReserva espacio para controles añadidos dinámicamente

RadioButtonBotón de radio (como en los formularios Windows)

RadioButtonList

Grupo de botones de radio

RepeaterPermite mostrar listas de controles (véase la sección "Data Binding")

Table Tabla

TextBox Caja de edición

XmlMuestra un fichero XML o el resultado de una transformación XSL

Controles de validación

Los controles de validación son un tip especial de controles ASP.NET que permiten validar las entradas de nuestra aplicación web. Cuando la entrada no verifica la condición que le imponemos a través de un control de validación, se le muestra un mensaje de error al usuario.

La validación de las entradas se realiza automáticamente cuando se pulsa un botón (ya tenga éste la forma de un botón estándar, Button, de una imagen, ImageButton, o de un enlace, LinkButton).

No obstante, se puede desactivar la validación si establecemos la propiedad CausesValidation del botón a false.

Por ejemplo, podemos forzar a que una entrada esté dentro de un rango válido de valores con un control de tipo RangeValidator:

Sólo tenemos que establecer la propiedad ControlToValidate (igual al TextBox que usamos como entrada), el mensaje de error que se mostrará (ErrorMessage) y la condición que ha de verificar la entrada (en este caso, su tipo, Type=Integer, y el rango de valores permitido, entre MinimumValue y MaximumValue).

Código fuente

Cuando los datos introducidos por el usuario son válidos, la aplicación prosigue su ejecución. Cuando no se verifica alguna condición de validación, se muestra el mensaje de error asociado y se le vuelve a pedir al usuario que introduzca correctamente los datos de entrada. Obviamente, la validación la podríamos haber realizado implementando la respuesta de nuestra aplicación a los eventos asociados utilizando controles web estándar, aunque de esta forma, ASP.NET se encargará de generar automáticamente las rutinas de validación. En el caso de que nuestro navegador acepte JavaScript, por ejemplo, la validación se realizará en el cliente, disminuyendo de esta forma la carga que ha de soportar el servidor de aplicaciones web.

Control de validación Descripción

CompareValidatorCompara el valor de una entrada con el de otra o un valor fijo.

CustomValidatorPermite implementar un método cualquiera que maneje la validación del valor introducido.

RangeValidatorComprueba que la entrada esté entre dos valores dados.

RegularExpressionValidator

Valida el valor de acuerdo a un patrón establecido como una expresión regular.

RequiredFieldValidatorHace que un valor de entrada sea obligatorio.

ValidationSummaryMuestra un informe con todos los errores de validación de la página.

Funcionamiento de las páginas ASP.NET

En una página ASP.NET, todos los controles cuyo funcionamiento haya de controlarse en el servidor deben estar incluidos dentro de nu formulario HTML (etiqueta <form>) con el atributo runat="server", el cual le indica al IIS que el formulario ha de procesarse en el servidor antes de enviárselo al cliente:

<form runat="server"> ... HTML y controles ASP.NET </form>

Este formulario, que ha de ser necesariamente único, es el que se encarga de facilitar la interacción del servidor con el cliente. De hecho, las páginas ASP.NET funcionan de una forma similar a los formularios Windows, si bien el modo de interacción de las interfaces web introduce algunas limitaciones ya que cada solicitud recibida por el servidor es independiente de las anteriores.

Postbacks

Al solicitar una página ASP.NET desde un cliente, en el servidor se dispara el evento Page_Load asociado a la página antes de generar ninguna salida. Es en este evento donde podemos realizar las tareas de inicialización de la página (rellenado de listas de valores, establecimiento de valores por defecto...).

El evento Page_Load se dispara CADA VEZ que se accede a la página. Si lo que queremos es ejecutar algo SÓLO LA PRIMERA VEZ, podemos emplear la propiedad Page.IsPostBack. Esta propiedad es false cuando el cliente carga por primera vez la página y true cuando la página se devuelve al servidor ("post back") al pulsar el usuario un botón del formulario web. El uso de "postbacks" es una técnica común

para manejar los datos de un formulario que consiste en enviar los datos a la misma página que generó el formulario HTML.

Estado de la página

ASP.NET nos ahorra tener que escribir mucho código al encargarse automáticamente de mantener el estado de los controles de los formularios web (ViewState). En ASP clásico, al enviar un formulario, todos sus valores se vacían, por lo que, si se ha producido un pequeño error en uno de los valores, tendremos que programar nosotros el código que se encargue de rellenar los valores que sí eran correctos (siempre y cuando queramos evitarle al usuario tener que introducir de nuevo todos los datos, claro está). Esto resulta bastante tedioso y propenso a errores. En ASP.NET, el formulario reaparece en el navegador del cliente con los valores que tuviese en el momento de enviarlo al servidor.

El estado de la página se define mediante un campo oculto denominado __VIEWSTATE que se le añade a cada página que tenga un formulario con el atributo runat="server", de forma que es el cliente el que se encarga de mantener el estado. Si visualizamos el código fuente de la página HTML que se muestra en el cliente, podemos ver algo así:

<input type="hidden" name="__VIEWSTATE"value="dDwtMjEwNjQ1OTkwMDs7PiTPnxCh1VBUIX3K2htmyD8Dq6oq" />

El mantenimiento del estado de la página es automático salvo que explícitamente indiquemos lo contrario:

A nivel de la página, podemos emplear la directiva <%@ Page

EnableViewState="false" %> en la cabecera del fichero .aspx.

A nivel de un control particular, podemos establecer su propiedad EnableViewState a false.

Antes teníamos que haber escrito algo como...<%@ Page language="c#" %><html><body><form runat="server" method="post">Tu nombre: <input type="text" name="nombre" size="20"><input type="submit" value="Enviar"></form><%string name = Request.Form["nombre"];

if (name!=null && name!="") {Response.Write("Hola, " + name + "!");}%></body></html>

En ASP.NET, no obstante, podemos teclear lo siguiente y evitar que el valor introducido desaparezca:<%@ Page language="c#" %><html><script runat="server">void enviar (object sender, EventArgs e){label.Text = "Hola, " + textbox.Text + "!";}</script><body><form runat="server" method="post">Tu nombre: <asp:TextBox id="textbox" runat="server" /><asp:Button OnClick="enviar" Text="Enviar" runat="server" /><p><asp:Label id="label" runat="server" /></p></form></body></html>

Data binding

IntroducciónListas de opcionesConjuntos de datos

Introducción

Se pueden asociar datos a las propiedades de los controles de la interfaz gráfica mediante tres mecanismos diferentes:

Podemos especificar los datos que deseemos en las etiquetas asociadas a los controles (<asp:... />), aunque sólo de forma estática, no dinámica.

Podemos implementar fragmentos de código que hagan uso del modelo orientado a objetos asociado a los controles de nuestros formularios. Ésta es la opción habitual que se emplea para rellenar

valores o listas sencillas (por ejemplo, en el evento Form_Load del formulario web).

En situaciones más complejas que requieran algo más sofisticado podemos utilizar un mecanismo denominado "data binding". En primer lugar, debemos disponer de un objeto que contenga los datos (DataSet, Array...). A continuación, asociamos ese objeto al control.

De esta forma, separamos claramente el código de nuestra aplicación de la interfaz de usuario.

Podemos enlazar el control a una amplia variedad de fuentes de datos: colecciones (Array, Hashtable, etc.), conjuntos de datos (DataSet, DataTable, DataView, DataReader), ficheros XML, propiedades, expresiones, llamadas a métodos...

Hemos de tener en cuenta que deberemos introducir código para actualizar en enlace (esto es, el mecanismo por defecto rellena una única vez las propiedades que hayamos enlazado ["one way snapshot model"]).

En las páginas ASP.NET podemos incluir expresiones de enlace a datos de la forma <%# expresión %> (de forma análoga a las etiquetas personalizadas de JSP en Java).

Listas de opciones

Se puede utilizar "data binding" para rellenar listas con elementos que provengan de alguna fuente de datos, ya sea ésta una base de datos, un fichero XML o un script. Los siguientes controles permiten utilizar listas en un formulario web ASP.NET: asp:RadioButtonList, asp:CheckBoxList, asp:DropDownList y asp:Listbox. Los elementos de dichas listas se suelen definir utilizando uno o varios componentes asp:ListItem, como en el siguiente ejemplo:

<html><body><form runat="server"><asp:RadioButtonList id="provincia" runat="server"><asp:ListItem value="GR" text="Granada" /><asp:ListItem value="AL" text="Almería" /><asp:ListItem value="MA" text="Málaga" /><asp:ListItem value="J" text="Jaén" /><asp:ListItem value="CO" text="Córdoba" /><asp:ListItem value="SE" text="Sevilla" /><asp:ListItem value="CA" text="Cádiz" /><asp:ListItem value="HU" text="Huelva" /></asp:RadioButtonList>

</form></body></html>

Sin embargo, resulta más adecuado utilizar una fuente de datos independiente para rellenar la lista. De esta forma, los datos se separan del HTML y cualquier cambio que se produzca en ellos será más fácil de hacer (al no tener que modificar los elementos de la lista en todos los sitios de la interfaz donde aparezcan, sino sólo en la fuente de datos, que debería ser única).

ArrayList

La colección ArrayList contiene una lista de objetos y podemos utilizarla para rellenar los elementos de una lista en nuestra interfaz.

Al cargar la página, creamos la lista y añadimos los elementos que nos hagan falta utilizando el método Add(). Una vez que tenemos los elementos en la lista, podemos ordenarlos con el método Sort(). Si los quisiéramos en orden inverso, no tendríamos más que llamar al método Reverse una vez que los tengamos ordenados. Finalmente, una vez que tenemos la lista con los elementos ordenados, sólo tenemos que enlazar la lista al ArrayList utilizando la propiedad DataSource del control y llamar al método DataBind() del control para rellenar nuestra lista:

private void Page_Load(object sender, System.EventArgs e){if (!Page.IsPostBack) {ArrayList list = new ArrayList();

list.Add("Granada");list.Add("Almería");list.Add("Málaga");list.Add("Jaén");list.Add("Córdoba");list.Add("Sevilla");list.Add("Cádiz");list.Add("Huelva");list.Sort();

provincia.DataSource = list;provincia.DataBind();}}

En este caso, los elementos del array se utilizan como texto (Text) y como valor (Value) asociado a los distintos elementos de la lista en nuestra interfaz, si bien esto no tiene por qué ser así siempre. Para emplear valores internos diferentes a las etiquetas que visualiza el usuario, podemos emplear colecciones de tipo Hashtable o SortedList.

Hashtable

Las tablas hash (Hashtable) contienen pares clave-valor y podemos utilizarlas si queremos emplear los códigos correspondientes a las provincias en vez de sus nombres completos, para lo cual hemos de indicar qué vamos a emplear como etiqueta (DataTextField) y qué como valor (DataValueField):

private void Page_Load(object sender, System.EventArgs e){if (!Page.IsPostBack) {Hashtable table = new Hashtable();

table.Add("GR", "Granada");table.Add("AL", "Almería");table.Add("MA", "Málaga");table.Add("J", "Jaén");table.Add("CO", "Córdoba");table.Add("SE", "Sevilla");

table.Add("CA", "Cádiz");table.Add("HU", "Huelva");

provincia.DataSource = table;provincia.DataValueField="Key";provincia.DataTextField="Value";provincia.DataBind();}}

El único inconveniente de las tablas hash es que no se puede elegir el orden de los elementos de la lista. Para poder ordenar los elementos deberemos emplear la colección SortedList, que se puede utilizar exactamente igual que la tabla hash y se mantiene ordenada automáticamente.

EJERCICIO: Utilizar una lista ordenada en vez de la tabla hash del ejemplo anterior.

Ficheros XML

Incluso podemos rellenar las listas de nuestra interfaz utilizando un fichero XML auxiliar como el siguiente:

<?xml version="1.0" encoding="ISO-8859-1"?><provincias><provincia><id>AL</id><nombre>Almería</nombre></provincia><provincia><id>CA</id><nombre>Cádiz</nombre></provincia><provincia><id>CO</id><nombre>Córdoba</nombre></provincia><provincia><id>GR</id><nombre>Granada</nombre></provincia><provincia><id>HU</id><nombre>Huelva</nombre></provincia><provincia><id>J</id><nombre>Jaén</nombre></provincia><provincia><id>MA</id><nombre>Málaga</nombre>

</provincia><provincia><id>SE</id><nombre>Sevilla</nombre></provincia></provincias>

Para hacer el enlace, construimos un DataSet a partir del fichero XML y enlazamos dicho DataSet al control:

private void Page_Load(object sender, System.EventArgs e){if (!Page.IsPostBack) {DataSet dataset = new DataSet();dataset.ReadXml(MapPath("provincias.xml"));

provincia.DataSource = dataset;provincia.DataValueField="id";provincia.DataTextField="nombre";provincia.DataBind();}}

PD: Por cierto, la propiedad SelectedItem de la lista es la que nos indica la opción seleccionada por el usuario, mientras que el evento SelectedItemChanged se produce cuando el usuario selecciona una de las opciones de la lista.

Conjuntos de datos

El control asp:Repeater sirve para mostrar conjunto de datos:

En primer lugar, añadimos un control asp:Repeater al formulario web. A continuación, podemos utilizar un conjunto de datos construido a partir del fichero XML que usamos en el último ejemplo de la sección anterior. Dicho conjunto de datos hemos de enlazarlo al control asp:Repeater:

protected System.Web.UI.WebControls.Repeater provincia;...

private void Page_Load(object sender, System.EventArgs e){if (!Page.IsPostBack) {DataSet dataset = new DataSet();dataset.ReadXml(MapPath("provincias.xml"));provincia.DataSource = dataset;

provincia.DataBind();}}

Finalmente, hemos de especificar cómo se visualizará cada dato de los que hemos enlazado al control asp:Repeater, para lo cual no nos queda más remedio que editar el código HTML de la página ASP.NET. Mediante el uso de plantillas definimos el aspecto visual de nuestro conjunto de datos:

<asp:Repeater id="provincia" runat="server"><HeaderTemplate><table border="3" cellpadding="5"><tr><th>Código</th><th>Nombre</th></tr></HeaderTemplate><ItemTemplate><tr><td><%# DataBinder.Eval(Container.DataItem, "id") %></td><td><%# DataBinder.Eval(Container.DataItem, "nombre") %></td></tr></ItemTemplate><FooterTemplate></table></FooterTemplate></asp:Repeater>

La plantilla <HeaderTemplate> se muestra al comienzo de la salida asociada al control asp:Repeater.

Para cada "registro" de nuestro conjunto de datos se utiliza la plantilla <ItemTemplate>. Esta plantilla la rellenamos con las etiquetas HTML que deseemos acompañadas de expresiones del tipo <%#

DataBinder.Eval(Container.DataItem, "campo") %> para visualizar los valores de los datos de nuestro conjunto de datos.

Por último, la plantilla <FooterTemplate> cierra la salida asociada al control asp:Repeater.

Opcionalmente, se puede utilizar una plantilla <AlternatingItemTemplate> para que las filas pares e impares se visualicen de forma distinta (p.ej. utilizando colores alternos).

Además, el control asp:Repeater incluye la posibilidad de utilizar una plantilla adicional (<SeparatorTemplate>) para describir lo que queremos que aparezca entre registro y registro.

EJERCICIO: Modificar el ejemplo anterior de forma que la tabla se muestre empleando colores alternos con ayuda de una plantilla de tipo <AlternatingItemTemplate>.

En ASP.NET existen otros controles aparte de System.Web.UI.WebControls.Repeater que se pueden emplear para visualizar e incluso modificar conjuntos de datos. En concreto, los controles System.Web.UI.WebControls.DataList y System.Web.UI.WebControls.DataGrid pueden ser de gran utilidad en el desarrollo de aplicaciones web.

El control asp:DataList es similar a asp:Repeater, si bien incluye por defecto una tabla alrededor de los datos y resulta más adecuado para su diseño desde el Visual Studio .NET, desde el que se pueden especificar sus distintas plantillas y definir su amplia gama de propiedades de forma visual (p.ej. estilos CSS). A las plantillas de asp:Repeater hay que añadir otras que permiten, por ejemplo, resaltar un elemento seleccionado dentro del conjunto de datos o editar su valor.

Finalmente, el control asp:DataGrid es aún más versátil a la hora de manipular conjuntos de datos (y más complejo a la hora de diseñar la aplicación, si bien es cierto el entorno nos ayuda mucho al poder diseñarlo de forma visual).

Sesiones de usuario

HTTPSesiones en ASP.NET

HTTP

El protocolo HTTP [HyperText Transfer Protocol] es un protocolo simple de tipo solicitud-respuesta, de modo que se establece una conexión diferente cada vez que accedemos a una página:

Cuando tecleamos la dirección de una página, el navegador web establece una conexión TCP con el servidor (usualmente a través del puerto 80). A continuación, el cliente envía un mensaje al servidor (solicitud) y éste le responde con otro mensaje (respuesta). Tras esto, la conexión se cierra y el ciclo vuelve a empezar. No obstante, hay que mencionar que, por cuestiones de eficiencia (reducción de la congestión en la red), HTTP/1.1 mantiene conexiones persistentes, lo cual no quiere decir que la interacción entre cliente y servidor varíe desde el punto de vista lógico.

HTTP sólo distingue dos tipos de mensajes (solicitudes y respuestas) que se diferencian únicamente en su primera línea. Tanto solicitudes como respuestas pueden incluir distintas cabeceras (del tipo clave:

valor) y un texto como cuerpo del mensaje.

El formato de una solicitud es de la siguiente forma:

GET http://elvex.ugr.es/index.htmlIf-Modified-Since: Thu, 31 Oct 2002 19:41:00 GMT

La primera línea de la solicitud, aparte de indicar la versión de HTTP utilizada, también determina el método utilizado para acceder al recurso identificado mediante un URI [Universal Resource Identifier], tal como se define en el RFC 2396. Los métodos más usados son GET y POST (que sólo se diferencian en la forma de pasar los parámetros de los formularios), así como HEAD (que sólo devuelve metadatos acerca del recurso solicitado).

La respuesta del servidor será del tipo:

HTTP/1.1 200 OKServer: Microsoft-IIS/5.0Date: Sun, 17 Aug 2003 10:35:30 GMT

Content-Type: text/htmlLast-Modified: Tue, 27 Mar 2001 10:34:52 GMTContent-Length: XXX<html>--- Aquí se envía el texto de la página HTML</html>

Como se puede apreciar, en la primera línea de la respuesta aparece la versión de HTTP empleada, un código de estado de tres dígitos y una descripción de ese código de estado. La siguiente tabla resume las distintas categorías de los códigos devueltos en las respuestas HTTP:

Código Significado

1xx Mensaje informativo

2xx Éxito (vg: 200 OK)

3xx Redirección (vg: 302 Resource temporarily moved)

4xxError en el cliente (vg: 400 Bad request, 401 Unauthorized, 403 Forbidden)

5xx Error en el servidor (vg: 500 Internal Server Error)

Cookies

HTTP, por definición, es un protocolo sin estado. Sin embargo, al desarrollar aplicaciones web, mantener el estado resulta imprescindible. Por ejemplo, en un sistema de comercio electrónico debemos ser capaces de almacenar de alguna forma el carrito de la compra de un cliente concreto.

Una primera solución a este problema (no demasiado acertada, por cierto) consiste en gestionar sesiones utilizando cookies (RFC 2965). Conforme navegamos vamos generando cookies ["galletitas"] en el cliente que luego se encargará de consumir el servidor. La idea es utilizar una cookie por servidor o grupo de servidores que se encargue de almacenar en el cliente la información que pueda necesitar el servidor (p.ej. los artículos que llevamos en el cesto de la compra).

Obsérvese que los datos asociados a una cookie se almacenan en la máquina cliente (usualmente sin ningún tipo de protección) y, por tanto, no deberían nunca incluir información cuya privacidad sería deseable mantener. Además, el uso de cookies lo provoca el servidor y no el cliente (Set-Cookie2), por lo que en determinadas situaciones puede resultar conveniente configurar el cliente para que ignore los cookies (no devolviendo la cabecera Cookie2 que le sirve al servidor para mantener la sesión)

Sesiones en ASP.NET

ASP.NET proporciona un conjunto de objetos que nos permiten gobernar la interacción entre el cliente y el servidor al desarrollar aplicaciones web. En realidad, todo ASP.NET se construye a partir del interfaz IHttpHandler:

IHttpHandler {void ProcessRequest (HttpContext context);bool IsReusable ();}

Para escribir nuestra aplicación web bastaría con construir una clase que implementase este interfaz y utilizar sentencias del tipo context.Response.Write("<html>...");. Como es lógico, esto no sería mucho mejor que programar CGIs y nosotros aprovecharemos los distintos objetos que nos proporciona ASP.NET para facilitarnos el trabajo. ASP.NET se encargará de compilar nuestra página construyendo una clase derivada de System.Web.UI.Page, la cual implementa la interfaz IHttpHandler

Los objetos más importantes con los que trabajamos en ASP.NET son los siguientes:

Objeto Representa...

HttpContext El entorno en el que se atiende la petición

Request La petición HTTP realizada por el cliente

Response La respuesta HTTP devuelta por el servidor

Server Algunos métodos útiles

ApplicationVariables globales a nivel de la aplicación (comunes a todas las solicitudes recibidas desde cualquier cliente)

SessionVariables globales a nivel de una sesión de usuario (comunes a todas las solicitudes de un cliente concreto)

Los dos últimos objetos son los que nos permiten manejar con comodidad las sesiones de usuario en ASP.NET y mantener el contexto en el que un usuario interactúa con una aplicación web. Mientras el usuario siempre interactúe con la misma página, ASP.NET se encarga de mantener el estado de ésta de forma automática. No obstante, en cuanto el usuario cambie de página (algo habitual en cualquier aplicación web real), tendremos que almacenar la información de su sesión de alguna forma:

Manualmente en el cliente, usando cookies a bajo nivel (una solución no demasiado buena).

Manualmente en el servidor, usando ficheros o, preferiblemante, bases de datos (la solución óptima en entornos distribuidos y sistemas tolerantes a fallos).

Automáticamente, usando las colecciones Session y Application facilitadas por ASP.NET. Dichas colecciones las podemos inicializar utilizando los métodos Session_Start y Application_Start del fichero global.asax.cs asociado a la aplicación web.

En el caso de la colección Session, ésta se comparte entre todas las solicitudes de clientes que utilicen el mismo identificador de sesión.

Dicho identificador se genera automáticamente cuando el cliente accede por primera vez a la aplicación web y se transmite desde el cliente cada vez que éste vuelve acceder a una página de la aplicación web.

El identificador de la sesión se puede transmitir utilizando la cookie ASP.NET_SessionId:cqcgvjvjirmizirpld0dyi5

o sin emplear cookies, incluyendo el identificador en la URL:http://servidor/aplicación/(uqwkag45e35fp455t2qav155)/página.aspx

Para acceder a la información de la sesión no tenemos más que utilizar la propiedad Session de nuestra página ASP.NET, ya que Session está definida en System.Web.UI.Page, la clase de la que derivan todas las páginas ASP.NET:

Inicialización en el fichero global.asax.cs:void Session_Start(){Session["UserName"] = "";}

En la página de entrada a la aplicación:void Page_Load (Object Src, EventArgs e){Session["UserName"] = TextBoxUser.Text;}

Desde las páginas internas de la aplicación:labelUser.Text = (string) Session["UserName"];

A diferencia de ASP, ASP.NET no requiere cookies y, aún mejor, permite configurar la forma en la que se gestionan las sesiones en la sección <sessionState ... /> del fichero web.config. Esto nos permite no tener que modificar el código de nuestra aplicación cuando, en vez de un único servidor, utilizamos un cluster y no queremos forzar la afinidad de un cliente a un servidor fijo.

Alternativas para gestionar las sesiones: InProc: En el proceso del servidor web (aspnet_wp.exe).

StateServer: En un proceso aparte compartido entre varios servidores web (aspnet_state.exe).

SqlServer: En un servidor SQL*Server.

La selección de una u otra alternativa implicará un compromiso entre la eficiencia y la fiabilidad en la gestión de sesiones para nuestra aplicación web.

Seguridad en .NET

Autentificación y autorización en IISFormularios de autentificación en aplicaciones web ASP.NET

Aunque la seguridad sea generalmente un tema obviado por la mayor parte de los programadores, en una aplicación web resulta un aspecto esencial. Planificar los mecanismos necesarios de seguridad para evitar accesos no autorizados a nuestras aplicaciones y servicios web se convierte, por tanto, en algo que todo programador debería saber hacer correctamente.

Cuando hablamos de seguridad en las aplicaciones web realizadas con la plataforma .NET, en realidad estamos hablando acerca de cómo restringir el acceso a determinados recursos gestionados por el Internet

Information Server (IIS) de Microsoft. Sin entrar en detalles de interés para los aficionados a las técnicas criptográgicas de protección de datos, a continuación veremos cómo implementar mecanismos de identificación de usuarios a través de contraseñas para acceder a sitios web desarrollados con páginas ASP.NET.

Autentificación y autorización en IIS

El funcionamiento habitual de una aplicación web que requiere la autentificación del usuario es redirigir a éste a un formulario de login cuando intenta acceder a un área restringida de nuestra aplicación web. Para lograrlo, nos basta con modificar un fichero de configuración y el IIS se encargará de hacerlo por nosotros.

En el directorio de una aplicación web se incluye un fichero XML de configuración llamado Web.config, cuya estructura se corresponde con la del siguiente ejemplo:

<configuration><system.web>

<authentication mode="Forms"><forms loginUrl="login.aspx" name=".ASPXFORMSAUTH"></forms></authentication>

<authorization><deny users="?" /></authorization>

</system.web></configuration>

La sección de autentificación (authentication) se utiliza para establecer la política de identificación de usuarios que utilizará nuestra aplicación:

Forms se emplea para utilizar formularios de autentificación en los que seremos nosotros los que decidamos quién accede a nuestra aplicación.

Passport permite que nuestra aplicación utilice el sistema de autentificación Passport de Microsoft (más información en http://www.passport.com).

Windows se utiliza para delegar en el sistema operativo las tareas de autentificación de usuarios, con lo cual sólo podrán acceder a nuestra aplicación los usuarios que existan en nuestro sistema.

Finalmente, None deshabilita los mecanismos de autentificación, con lo que cualquiera puede acceder a ella desde cualquier lugar del mundo sin ninguna restricción de acceso.

Cuando selecccionamos el modo de autentificación Forms hemos de indicar también cuál será el formulario encargado de que nuestros usuarios se identifiquen al usar el sistema (login.aspx) en el ejemplo de arriba.

A continuación, la sección de autorización (authorization) se utiliza, en el mismo ejemplo, para restringir el acceso a los usuarios no identificados.

Un fichero Web.config restringe el acceso a un directorio y a todos sus subdirectorios, si bien en los subdirectorios se pueden incluir otros ficheros Web.config que redefinan las restricciones de acceso a los subdirectorios del directorio principal de nuestra aplicación web.

Por ejemplo, si en una parte de nuestra aplicación queremos que cualquier persona pueda acceder (incluso sin identificarse), basta con incluir la siguiente autorización en el fichero de configuración correspondiente:

<authorization><allow users="*" /></authorization>

Si lo que quisiéramos es restringir el acceso a un usuario particular, sólo rendríamos que incluir la siguiente sección de autorización en nuestro fichero Web.config:

<authorization><deny users="*" /><allow users="administrador" /></authorization>

Incluso podríamos haber puesto una lista de nombres de usuario separados por comas.

Podemos crear una aplicación web a la cual sólo tendrán acceso algunos usuarios de nuestra máquina si utilizamos "Windows" como mecanismo de autentificación y restringimos el acceso anónimo al directorio donde alojamos la aplicación en IIS (Panel de control > Herramientas administrativas > Administración de equipos > Servicios y Aplicaciones > Servicios de Internet Information Server):

Una vez hecho esto, modificamos el fichero Web.config de acuerdo a nuestras necesidades y, cuando intentemos acceder a la aplicación nos aparecerá una ventana como la siguiente:

Si tras varios intentos no introducimos un nombre de usuario

válido y su contraseña correcta, el servidor web nos devolverá un error de autentificación "HTTP 401.3 - Access denied by ACL on resource":

Formularios de autentificación en aplicaciones web ASP.NET

En determinadas ocasiones no nos podemos permitir el lujo de crear un usuario en el sistema operativo para cada usuario que pueda acceder a nuestra aplicación, por lo que seremos nosotros los encargados de gestionar los usuarios y el acceso de éstos a las distintas partes de nuestras aplicaciones.

Cuando un usuario intente acceder a una página cuyo acceso esté restringido, el usuario será redirigido a un formulario específico de login, que, al menos, incluirá dos campos para que el usuario indique su nombre y su clave (dos controles de tipo TextBox, especificando la propiedad TextMode=Password para la caja de edición correspondiente a la contraseña de acceso). En dicho formulario para comprobaremos el identificador y la clave del usuario:

if ( textBoxID.Text.Equals("usuario") && textBoxPassword.Text.Equals("clave") ) {

FormsAuthentication.RedirectFromLoginPage(textBoxID.Text,false);

} else {

// Error de autentificación...}

Cuando el usuario se identifica correctamente, lo único que hacemos es indicarle al IIS que le permita al usuario acceder a la página a la que inicialmente deseaba acceder. Para ello utilizamos un método de la clase FormsAuthentication que está incluida en el espacio de nombres System.Web.Security. El IIS se encargará de todo lo demás por nosotros.

Cuando el usuario no introduzca una clave de acceso correcta o su identificador no exista en nuestra base de datos de usuarios registrados, podemos mostrarle un mensaje de error informativo mediante una etiqueta (labelMessage.Text=...) o redirigir al usuario a la página que nos interese utilizando el método Response.Redirect("http://...");. Esto último lo podríamos utilizar si estamos construyendo un sistema en el cual permitimos que los usuarios puedan registrarse ellos mismos.

Creamos una aplicación web con dos formularios, uno de los cuales lo utilizaremos como formulario de identificación:

En primer lugar, debemos configurar correctamente el fichero Web.config, tal como se muestra a continuación:

<authentication mode="Forms"><forms loginUrl="Login.aspx" name=".ASPXFORMSAUTH"></forms></authentication>

<authorization><deny users="?" /></authorization>

Al intentar acceder a cualquier formulario de nuestra aplicación, si no estamos identificados se nos redirecciona al formulario de login:

Si no introducimos incorrectamente la clave de acceso, se nos debería mostrar un mensaje informativo de error:

Obviamente, en una aplicación real no deberíamos ser tan

explícitos ;-)

Sólo cuando nos identifiquemos correctamente podremos acceder a la aplicación:

IMPORTANTE: Con lo que hemos visto, conseguimos controlar el acceso a nuestras aplicaciones web, aunque éstas aún no son realmente seguras porque los datos se transmiten tal cual, sin encriptar. Para proteger los datos que se transmiten entre el servidor web y los clientes que acceden a él debemos configurar el servidor web para que pueda utilizar el protocolo HTTPS. Este protocolo utiliza técnicas criptográficas de clave pública y nos hará falta instalar un certificado (un par clave pública-clave privada) para que podamos acceder al servidor usando https://...