VELOCIDAD DE ESCAPE

Mira, Joma, yo tengo esa polémica todos los días en mi empresa: son todos javeros y a mí me están reciclando de .NET, y me encuentro más solo que la una defendiendo a MS contra las hordas de Sun :)

El caso es que se pueden comentar diferencias en arquitecturas, en rendimiento de la aplicación, incluso si me apuras en entorno de desarrollo (aunque en el caso de los javeros lo llevan claro en este apartado), y así ad nauseam.

Pero donde creo que tienen TODAS las de perder es en el tiempo de desarrollo de la aplicación, que es un factor fundamental para calcular el coste de la misma, por cierto. No hay color: cualquier cosa se desarrolla más deprisa en .NET, desde un "Hola, mundo!" en consola hasta una aplicación de n-capas complicada de la rehostia. Y como al fin y al cabo a los clientes se les cobra por horas de proyecto, aún no sé cómo salen tantas cosas en Java.

Mi conclusión es que el equipo de desarrollo usando herramientas de IBM es más caro que el otro, nada más. La diferencia de precios es a todas luces excesiva.

Hombre, charlie, si resulta que se cobra por horas de desarrollo está muy claro porqué se usa JAVA.
Te cobran mucha más pasta.

Hispasec: Microsoft anuncia la investigación de un problema en ASP.NET

Microsoft está investigando una vulnerabilidad sobre la que han sido informados que afectaría a la plataforma ASP.NET. La vulnerabilidad en la tecnología ASP.NET de Microsoft puede ser utilizada por un atacante para acceder a áreas protegidas mediante contraseña alterando la URL.

Este problema es específico de ASP.NET, no afecta a ASP y podría deberse a que dicha plataforma no realiza correctamente el proceso de canonización de algunas URLs. El problema afecta a los sitios web que
usen cualquier versión de esta plataforma sobre Windows 2000, 2000 Server, XP Professional y 2003 Server.

Aunque la información proporcionada por el momento es más bien escasa, cabe señalar que no es habitual que Microsoft adelante información sobre vulnerabilidades, lo que levanta las sospechas sobre la gravedad
del problema. Todo indica que la vulnerabilidad debe ser fácil de explotar, en la que bastaría modificar o añadir un carácter en la URL para permitir el acceso a contenidos sin autorización.

El artículo del Knowledge Base 887459 ("Programmatically Checking for Canonicalization Issues with ASP.NET") describe formas de añadir mecanismos adicionales de protección contra problemas de este tipo, por lo que se recomienda su lectura y aplicación en los programas que pudieran verse afectados. La dirección de dicho artículo es la
siguiente: http://support.microsoft.com/?kbid=887459

Como ya he dicho en el anterior post, este agujero está solucionado desde hace tiempo con el correspondiente parche.

Y no vamos a empezar a sacar trapos sucios de Java ¿no?

Y desde hace tiempo cualquier programador ASP sabe, que la autenticación debe de manejarse a lo largo de toda la aplicación al menos en cada página mediante cookies u otro método además del implementado en la página de login mediante sesión u otro método empleado.
Eso ya desde ASP 3 era bien sabido.
Nunca pongas todos los huevos en la misma cesta.

Supongo que, en aras de la completitud, debe añadirse la opinión de IBM (la parte perdedora de la comparativa).