Parche para debugear aplicaciones ASP.NET en IIS7

Los que uséis VS 2005 para debugear aplicaciones ASP.NET en IIS7 en Windows Vista podéis encontraros uno de los siguientes errores cuando pulsáis F5 para enlazar el debugger en el IDE:

  • «An authentication error ocurred while communicating with the web server». (Ocurrió un error de autenticación mientras se comunicaba con el servidor web).
  • «Debugging failed because integrated Windows authentication is not enabled». (Falló el debugging porque la autenticación integrada de windows no está habilitada).
  • «Authentication error occurred while communicating with the web server.  Try disabling ‘Digest authentication'». (Ocurrió un error de autenticación mientras se comunicaba con el servidor web. Pruebe a deshabilitar ‘Digest authentication’).

Estos errores ocurren debido a la forma en que VS 2005 busca el ID del proceso IIS7 en donde se está ejecutando ASP.NET. Cuando usamos F5 para «autoenlazar» el debugger con Visual Studio le manda una petición HTTP a ASP.NET usando la autenticación de Windows para obtener los detalles del proceso. Esto funciona bien si tenéis habilitada la autenticación de windows en el servidor web, y se está usando la autenticación de Windows como método principal de autenticación en nuestra aplicación web. Sin embargo, los problemas llegan bajo ciertas circunstancias:

  1. Si tenemos habilitada la autenticación por formularios en ASP.NET y estamos ejecutando el «modo integrado» en IIS7. Esto bloquea el manejador del proceso.
  2. Si no tenemos el módulo de autenticación de Windows instalado en el servidor web (ahora es un componente opcional).
  3. Si estamos ejecutando Windows Vista Home (que no soporta el módulo de autenticación de windows).

Descarga del parche.

Para solucionar estos casos que bloquean el «autoenlazado», hemos publicado un parche para Visual Studio 2005.  Soluciona los problemas de los que hemos hablado antes. Podéis descargarlo desde aquí. Una vez que lo instaléis, cuando pulsemos F5 en Visual Studio todo funcionará como antes.

Podeis leer más sobre este parche y sobre los errores que corrige en este artículo, y en los siguientes post aquí y aquí.

Si tenéis algún problema instalando el parche o si continuais con los mismo problemas una vez instalado, podéis contactar con el soporte de Microsoft. La llamadas a soporte son gratuitas si están relacionadas con un bug de un producto. Podeis ver los detalles sobre cómo contactar con soporte en esta página.

Cómo enlazar manualmente el debugger a un proceso.

He ayudado a varias personas con este problema ántes de que se publicase el parche. Una de las cuentas de las que me di cuenta mientras lo hacía fué que un montón de desarrolladores no se dan cuenta de las opciones disponibles cuando están debuggeando, y las diferentes formas que podemos usar Visual Studio para debugear un proceso o aplicación.

Cuando pulsamos F5 en Visual Studio (DebugStart Debugging) le estamos diciendo a Visual Studio que arranque la aplicación y que la enlaze al debugger. Una alternativa que podemos usar es debugear una aplicación que ya está siendo ejecutada en el menú DebugAttach to Process…

Cuando seleccionamos ese menú, nos muestra un cuadro de diálogo que nos mostrará los procesos en ejecución (también podemos indicar una dirección IP para debugear en una máquina remota):

Si queremos debugear una aplicación ASP.NET que se está ejecutando en IIS, aseguraos de marcar el checkbox de «Show processes in all sessions» (desde que IIS se ejecuta como un servicio de windows y como una cuenta local). Luego, buscamos en la lista el proceso w3wp.exe (es el nombre del proceso de IIS6  e IIS7).

Haciendo doble clic en cualquier proceso hará que Visual Studio enlaze el debugger a ese proceso – en este punto, todos los puntos de ruptura que hallamos definido se lanzarán y ya podremos debuggear cualquier proceso con VS2005 como si lo hubiésemos lanzado con F5. Esto funciona tanto para aplicaciones web como para aplicaciones windows, y puede ser muy útil cuando ya tenemos la aplicación en ejecución. Daros cuenta de que ya no tendréis que hacer esto si tenéis instalado el parche.

Espero que sirva.

Scott.

Traducido por: Juan María Laó Ramos. Microsoft Student Partner.

toH tlhIngan Hol DajatlhlaH ‘e’ DaneH’a’?

IIS 7.0 Beta 3 sale con una licencia Go-Live

Esta semana lanzamos IIS 7.0 Beta 3 como parte de la release de Windows «Longhorn» Server. IIS 7.0 es la mayor release de IIS en la historia del producto, y viene con muchas mejoras para la pila de los servidores web de Microsoft. En este artículo y este post encontraréis una lista de unas cuantas de esas mejoras que nos aporta.

Nuevas características en IIS 7.0 Beta 3.

Esta semana, la release de IIS 7.0 beta 3 nos trae un montón de nuevas características y capacidades más allá de las que venían con la release de Windows Vista. Entre otras están:

  • Configuración compartida en granjas de servidores: Ahora podéis configurar vuestros servidores centralizando toda la configuración, código y contenido en una granja de servidores (haciendo que sea mucho más fácil de escalar y administrar). Aquí podeis ver cómo usar esta nueva característica.
  • Delegar la administración remota: Podéis usar la herramienta de administración de IIS7 para administrar remotamente servidores web sobre HTTP/SSL. Los administradores pueden ahora bloquear y delegar configuraciones para administradores de sitios – habilitando un control más fino sobre quién administra los sitios en la máquina (ideal para escenarios de hosting).
  • Aislamiento automático del pool de aplicaciones: IIS 7.o hace mucho más facil el acceso y el aislamiento del pool de aplicaciones de los procesos en el servidor web. Esto es ideal para escenarios de hosting, así como para escenarios de empresas donde queráis tener un aislamiento completo y sandboxing entre aplicaciones.
  • Soporte interno para FastCGI para PHP y otras extensiones: además de permitir una gran extensibilidad para .NET, IIS7.0 ahora trae incluido suporte para extensiones FastCGI – haciendo realmente fácil de usar con frameworks dinámicos para servidores web como PHP.
  • Nuevo servidor FTP: El nuevo servidor FTP de IIS 7.0 incluye soporte para la publicación segura con FTP/SSL, soporte para host header FTP, soporte para una herramienta integrada de administración, y soporte para sistemas de autenticación empotrados (usando el mismo modelo de proveedores que el sistema de membership que ASP .NET.

Aseguráos de leer el post de Bill Staples para aprender más sobre todas las características anteriores.

Licencia Go-Live de IIS 7.0

Después de meses de test de stress en nuestros laboratorios, creemos que IIS7 está listo para afrontar despliegues de clientes. Para facilitar esto, Microsoft ofrecen una licencia especial Go-Live para IIS7 y Windows Server «Longhorn» Beta3. Esto os permitirá desplegar servidores IIS en entornos de producción inmediatamente (nota: Hemos desplegado www.microsoft.com en esta build).

Podéis aprender más sobre la licencia Go-Live de IIS7, así como saber cómo descargaros gratuítamente Windows Server «Longhorn» Beta 3 aquí.

Como alternativa, podéis registraros para obtener una cuenta de hosting en IIS7 Beta en alguno de los web hosters que han desplegado IIS7 Beta 3. Podéis conocer los detalles de sus ofertas aquí.

Espero que sirva.

Scott.

Traducido por: Juan María Laó Ramos. Microsoft Student Partner.

Trucos: Habilitar SSL en IIS 7.0 usando certificados firmados por nosotros

SSL permite que los navegadores se comuniquen con un servidor web sobre un canal seguro para evitar que nadie pueda «escuchar» la comunicación, interceptar y falsificar mensajes. Deberíamos usar SSL en las páginas de login donde los usuarios introducen sus nombres de usuario y contraseñas, así como en todas las web de un sitio que puedan ser «sensibles» (por ejemplo: páginas que muestren información financiera o personal).

Configurar SSL en Windows con versiones anteriores de IIS ha sido siempre un quebradero de cabeza. Hay que saber cómo instalar y administrar un certificado, y luego asociarlo a un sitio web, seguro que es algo que la mayoría de desarrolladores web no saben cómo habilitar.

Las buenas noticias son que IIS 7.0 hace radicalmente fácil configurar y habilitar SSL. IIS 7.0 además trae soporte de fábrica para crear nuestros propios certificados de forma sencilla para habilitar rápidamente un sitio web SSL para desarrollo o para test.

Con IIS 7.0 podemos habilitar un sitio web ya creado con SSL en tan sólo 30 segundos. El siguiente tutorial muestra cómo hacer eso.

Paso 1: Crear un nuevo sitio web.

Empezaremos creando un nuevo sitio web con la nueva herramienta de administración de IIS7.0. Esta herramienta de adminstración ha sido reescrita completamente a partir de la versión anterior (que fué escrita usando código manegado con Windows Forms), y provee una organización más lógica de características web. Da una experiencia de administración con una interfaz gráfica (GUI) para todas las configuraciones de ASP.NET e IIS:

SSLIISStep0

Para crear un nuevo sitio, clic con el botón derecho en el nodo «Web Sites» en el árbol del lado izquierdo y elegir la opción «Add Web Site» del menu contextual. Añadimos los detalles necesarios para crear el nuevo sitio web:

SSLIISStep1

Una gran característica de IIS7 en Windows Vista es que podemos tener un número ilimitado de sitios web en una caja (las versiones anteriores de IIS en clientes Windows sólo nos permitía un sitio). La limitacion de 10 peticiones simultaneas en las versiones de IIS para clientes Windows no existe ahora en IIS7.

Paso 2: Crear un certificado propio.

Antes de enlazar reglas SSL a nuestro sitio, necesitamos importar e instalar un certificado de seguridad para usarlo en el enlace SSL.

Los certificados se administran en IIS7 haciendo clic en el nodo root del árbol de la izquierda, y seleccionamos el icono «Server Certificates» en el lado derecho:

ssliisstep3

Esto nos mostrará una lista de todos los certificados registrados en la máquina, y nos permitirá importar y/o crear otros nuevos.

Opcionalmente, podemos irnos a una entidad emisora de certificados como Verisign y comprar un certificado para importarlo con esta herramienta de administración. O podermos crear nuestro propio certificado para que funcione como un certificado de prueba que podamos usar para el desarrollo y las pruebas en nuestro sitio. Para hacer esto, tenemos que hacer clic en el link «Create Self-Signed Certificate» en la parte derecha de la herramienta de administración:

ssliisstep4

Metemos el nombre para usar el certificado (por ejemplo: «test») y hacemos clic en ok. IIS7 creará automáticamente un nuevo certificado encriptado y lo registrará en la máquina:

Paso 3: Habilitar los enlaces HTTPS para nuestro nuevo sitio.

Para habilitar SSL en nuestro nuevo sitio web, seleccionamos el nodo del web side en el árbol de la izquierda, y hacemos clic en link «Bindings»del menú «actions» del lado derecho de la pantalla:

Esto nos mostrará un cuadro de dialogo que nos mostrará todas las reglas de enlace que dirigen el tráfico a este sitio (significando las combinaciones de cabeceras host/direcciones ip/puerto para el sitio):

Para habilitar SSL en el sitio, haremos clic en el boton «Add». Esto nos mostrará otro cuadro de dialogo  para añadir soporte para el protocolo HTTPS. Podemos seleccionar el certificado que hemos creado de la lista desplegable del diálogo, para indicar que queremos usar ese certificado cuando encriptemos contenido sobre SSL:

Hacemos clic en OK y ya tenemos habilitado SSL para nuestro sitio:

Paso 4: Probando nuestro sitio.

Añadimos una página «default.aspx» al sitio, e intentamos abrirla con el navegador escribiendo https://localhost/default.aspx (usamos «https» en lugar de «http» para indicar que queremos conectarnos a través de SSL).

Si usamos IE7, vereis el error de anti-phising:

No os alarméis si os pasa esto – tan sólo es el IE que nos advierte que un certificado creado por nosotros es sospechoso. Hacemos clic en el link «Continue to this website» para saltarnos este aviso de seguridad e ir al sitio. Encontraremos nuestra pagina default.aspx  corriendo sobre SSL:

Y ya está echo. 🙂

Apendice: Últimas notas sobre SSL.

  • La herramienta de administración de IIS7 tiene un nodo de configuración «SSL Settings» que podemos seleccionar para cada sitio, directorio o archivo que nos permite controlar cuándo, ese recurso particular (y por defecto a todos sus hijos), requiera peticiones SSL para ejecutarse. Esto es muy útil para páginas como login.aspx, cuando queremos garantizar que los usuarios metan sus credenciales cuando el canal esté encriptado. IIS 7 bloqueará a todos lo navegadores que intenten acceder a menos que lo hagan sobre SSL.
  • En una pagina ASP.NET, podemos saber programáticamente, cuándo la petición actual está usando SSL chequeando la propiedad Request.IsSecure (devolverá «true» si la petición viene por SSL).
  • Podemos poner el atributo «requireSSL» en la sección de configuración de <forms> en el web.config para tener el sistema de autentificación por formulario de ASP.NET y asegurarnos que las cookies sólo se usan en sitios con SSL. Esto evita el riesgo de que un hacker intercepte una cookie de autentificación en una página sin SSL, e intente usar el «ataque por repeticion» desde una máquina diferente para suplantar la identidad de un usuario.

 Para más información de IIS/, leeros mi anterior post sobre IIS7. También echadle un vistado a la web www.iis.net.

Para leer mas sobre mis post sobre trucos, visitad mi página sobre trucos

Espero que sirva.

Scott.

Traducido por: Juan María Laó Ramos. Microsoft Student Partner.