Imagina la siguiente situación, bastante común por otro lado:

Estás desarrollando una aplicación JavaScript (generalmente de tipo Single Page Application), y utilizas la biblioteca require.js para realizar la modularización de la misma en lado cliente. Vas tocando tu código JavaScript y probándolo y depurándolo en diferentes navegadores. Eso implica lanzarlos con bastante frecuencia, albergando tu aplicación en un servidor web local para probar la aplicación. El problema surge porque el servidor web hace caché de los archivos estáticos (como son los .js) por lo que cada vez que cambias algo en un script, aunque refresques la página, no siempre vienen los cambios que has realizado.

Esto puede conducir a grandes frustraciones porque a veces cambias un carácter o una línea, crees que estás probando esa última versión, pero en realidad estás trabajando todavía con la versión anterior antes de los cambios. Hasta que te das cuenta pasan unos minutos preciosos que has perdido…

Obviamente puedes desactivar la caché del servidor y forzar siempre la descarga desde el cliente con ciertas cabeceras que se envían con todos los archivos. Pero esto es tedioso de configurar y además afectará seguramente a todos los archivos estáticos (o no, pero tendrás que tocar bastante configuración para lo contrario), no solo a los archivos JavaScript.

Si estás usando require.js para gestionar los diferentes módulos de la aplicación, existe un parámetro de configuración muy interesante que te permitirá solucionar de manera sencilla el problema de la caché.

LEER MÁS AQUÍ: http://www.jasoft.org/Blog/post/Forzar-siempre-la-descarga-sin-cache-cuando-usas-requireJS-en-aplicaciones-JavaScript.aspx

Normalmente cuando desarrollas una aplicación web lo haces pensando en colocarla en Internet, abierta a todo el mundo. En estos casos lo que haces es habilitar la autenticación de usuarios bien a través de unas credenciales que introducen en tu aplicación y que validas contra la base de datos, o bien a través de algún servicio de autenticación de terceros (como autenticarse con Facebook, Twitter, Google o GitHub).

Lo que ocurre es que algunas aplicaciones web están pensadas para trabajar en la red interna de una empresa o , aunque sea a través de Internet, utilizando la infraestructura de Directorio Activo para autenticar a los usuarios.

Para estos casos es necesario activar la denominada "Autenticación Windows" en tu servidor Internet Information Server.

Ésta permite validar usuarios del dominio (o de la máquina local) contra la infraestructura de la empresa, de modo que se identifican por el mero hecho de estar autenticados en la máquina local, usando su usuario y clave habituales. La autenticación del usuario además es totalmente transparente, es decir, ni siquiera tienen que introducir sus credenciales.

Enseguida vamos a ver cómo funciona esto, pero antes debes conocer sus limitaciones:

• Solo funcionará si el ordenador cliente (en el que está el navegador) y el servidor están dentro del mismo dominio.
• No sirve para acceder con ordenadores que utilicen algún tipo de proxy o que estén detrás de un firewall ya que ambas máquinas (cliente y servidor) necesitan una conexión directa (en el caso de Kerberos) o no soportan proxies HTTP (en el caso de NTLM). Esto hace difícil que funcione a través de Internet. Una solución sería utilizar los servicios de Directorio Activo de Azure, pero implica que la autenticación la haga la aplicación web, no IIS).
• El navegador que lo soporta mejor es Internet Explorer, aunque también funciona con Chrome/Opera y Safari, y se puede hacer funcionar con Firefox con configuración adicional.

De esto se deduce que el ambiente ideal para esta característica son las Intranets de empresa.

Sigue leyendo para saber:

• Cómo funciona la autenticación Windows
• ¿Cómo instalar y configurar la autenticación Windows en IIS?
• ¿Cómo la activo en ASP.NET o en aplicaciones web en general?
• ¿Cómo la activo en IIS Express?