A la hora de desplegar en un entorno real de producción, para ponerlas a disposición de todo el mundo, las aplicaciones web creadas con ASP.NET se albergan en un servidor web. Por regla general éste será Internet Information Server (IIS), incluido en las versiones de servidor de Windows. IIS no es más que otra aplicación que se ejecuta sobre el sistema operativo, por lo que es Windows el que se ocupa del nivel más bajo de la cadena de la seguridad. Por ello conviene tener claro que la última palabra a la hora de conceder acceso a un recurso físico del sistema la tiene el propio sistema operativo, no IIS ni ASP.NET. Contextos de seguridad En Windows, cada proceso se ejecuta dentro de su propio contexto de seguridad. Cuando un proceso accede, por ejemplo al sistema de archivos NTFS, los permisos se le otorgan en función del contexto en el que se ejecute. Normalmente si un proceso lanza otro subproceso éste ... [Más]

Hace unos tres años Microsoft lanzó IISExpress, una versión ligera de su servidor Web y servidor de aplicaciones, pensada fundamentalmente para ser utilizada por parte de los desarrolladores. Hasta entonces cuando queríamos probar y depurar una aplicación web desde Visual Studio teníamos básicamente dos opciones: Usar el servidor de desarrollo integrado, conocido comúnmente como “Cassini”. El problema es que no era el servidor verdadero y había ciertas diferencias con un entorno de producción real. Además no permitía usar otras tecnologías como PHP o ASP Clásico, y a veces era necesario por que tenemos aplicaciones mixtas. Usar el propio Internet Information Server, que sí que era ya como el entorno real y no tenía ningún tipo de limitaciones. El problema es que para poder usarlo necesitas permisos de administrador y además implica configurar el ... [Más]

Un poco de historia para comenzar y ayudarnos a entender el porqué de lo que voy a explicar. Cuando nació ASP.NET hace ya casi 15 años lo único que existía era ASP.NET Web Forms. Este novedoso paradigma de desarrollo trataba de acercar el desarrollo web a los programadores de escritorio, y permitía arrastrar y soltar controles, controlar eventos en el servidor como si fueran eventos de cliente, etc… Algo muy innovador y que todavía sigue siendo muy útil (y muy utilizado), pero que cada vez se usa más para ciertos ámbitos concretos, como las aplicaciones empresariales. Una década más tarde Microsoft decidió que aunque esto estaba muy bien para crear rápidamente aplicaciones de tipo empresarial no daba la flexibilidad apropiada para crear aplicaciones web generales, donde se necesitaba un control absoluto sobre el HTML generado, y se necesita poder sacar partido con total libertad a... [Más]

Por defecto, ASP.NET 4.5 (con Visual Studio 2012) cambió la manera en la que funciona la vali [Más]

El evento Application_End se desata en una aplicación Web cuando ésta termina por cualquier motivo, aunque sea para reiniciarse. Escribimos un gestor de este evento dentro de Global.asax en el que incluimos cualquier tipo de código que se encargará de dejar en el estado correcto cualquier recurso global que hayamos inicializado en el evento complementario que se lanza cuando arranca la aplicación: Application_Start. Esto es válido tanto para aplicaciones Web Forms como MVC. El código que pongamos en estos eventos se lanzará únicamente cuando se arranque y se detenga la aplicación. Si queremos depurarlo desde Visual Studio, usando el servidor de desarrollo (que es lo habitual), la cosa tiene algo de truco. El problema es que no es tan fácil conseguir que se cierre la aplicación y que puedas depurarlo al mismo tiempo. Al contrario de lo que muchos programadores se piensan, cerrar el navegador no detiene la aplicación, que sigue activa por detrás, sólo cierras la sesión actual del u... [Más]

Este es un error muy típico en algunas aplicaciones y me he acordado de él a raí [Más]

A la hora de trabajar con sesiones en C#, el mayor problema es que, al contrario que en VB, no se facilita el manejo directo de los valores como si fueran propiedades del objeto Session ni se transforman al tipo correcto para hacer operaciones como Session("Contador")++ y similares. Además, adicionalmente, hay que comprobar que las variables existan antes de poder hacer todas estas operaciones. Por ejemplo, si queremos trabajar con una cadena de texto en sesión y poder asignarle un valor, se trata de algo tan sencillo como lo es en VB ya que sólo debes asignarla directamente, así: 1: Session["TextoAGuardar"] = "Este es el texto que quiero almacenar"; Sin embargo si lo necesitamos es realizar una operación matemática es un poco más lioso ya que deberemos comprobar primero que la variable existe y contiene un valor, y ademas convertirla desde "object" que es lo que devuelve por defecto una variable de sesión, al tipo correc... [Más]

ASP.NET Web Forms ofrece unos maravillosos controles de validación que nos permiten controlar los valores de los campos de un formulario tanto en el navegador como luego en el servidor. Así, basta con arrastrar unos cuantos controles sobre la página para validar campos obligatorios, rangos de valores, expresiones regulares, tipos de datos introducidos, etc... Incluso podemos definir nuestras validaciones personalizadas, si bien esto requiere mucho más esfuerzo por nuestra parte. Estos controles están muy bien pero, en el lado de cliente (navegador), se limitan a mostrar mensajes cuando falla alguna validación: Los mensajes podemos agruparlos en un control de resumen y cambiar el estilo que utilizan, pero no nos permiten apenas configuración del lado cliente. ¿Qué pasa si lo que necesitamos es tener mayor control sobre lo que ocurre en el navegador durante la validación? ¿Podemos hacer algo sin complicarnos demasiado la vida? Por ejemplo, un caso muy típico es querer destacar los ... [Más]

Hasta ahora con Transfer y Execute hemos visto que podemos ejecutar otras páginas del mismo tipo sin necesidad de redirección desde el lado cliente. Sin embargo un efecto secundario que tiene su uso es que, como no se regenera la petición sino que se ejecutan dentro del contexto de la petición actual, no entran en juego los controles de seguridad y otros eventos del pipeline HTTP para la segunda página. Es por ello por lo que en nuestro ejemplo se ha podido mostrar el contenido de la página "P2.aspx" a pesar de que estaba protegida. Existe una variante de estos métodos llamada TransferRequest que permite conseguir una petición completa desde el propio servidor, sin pasar por el cliente como ocurría con Redirect. Este método se utiliza del mismo modo que Transfer pero en este caso la segunda página pasa por todo los estadios de una petición HTTP normal, como si hubiera sido hecha desde el cliente desde... [Más]

En la entrega anterior de esta serie vimos a fondo cómo funcionaba el método Transfer. Seguimos ahora profundizando en otros métodos relacionados. El método Transfer por debajo lo único que hace es llamar al método Execute de la misma clase HttpUtility: Este método es prácticamente idéntico a Transfer, como vemos en este código, por lo que a todos los efectos podemos sustituir las llamadas a Transfer por llamadas a Execute y no perder funcionalidad. Además, si nos fijamos en el código de Transfer de una figura anterior, llama continuación a Response.End. Esto como ya vimos en la primera parte con Redirect, tiene algunas implicaciones respecto al rendimiento debido a la generación de excepciones ThreadAbortException, por lo que en sitios muy grandes donde cada milésima cuenta puede ser interesante sustituir las llamadas a Transfer por llamadas a Execute con una posterior a CompleteRequest (repasa el primer post para verlo). Si hacemos lo mismo que antes pero llamando a Execute en ... [Más]