w3schools tutorial programacion net lenguaje definicion asp asp.net asp-classic

tutorial - Integración clásica ASP y ASP.NET



w3schools com asp net (5)

En un trabajo anterior teníamos una aplicación ASP clásica que nadie quería migrar a ASP.NET. Las cosas que hizo, lo hicieron muy bien.

Sin embargo, había algunas nuevas funcionalidades que debían agregarse que parecían más adecuadas para ASP.NET. Se tomó la decisión de permitir que el sistema se convierta en un híbrido extraño de ASP y ASP.NET.

Nuestro mayor punto de fricción fue la gestión de sesiones y hackamos juntas una solución para pasar los valores de la sesión a través de variables de formulario. He hablado con otras personas que manejan este mismo problema a través de las cookies.

Ambos métodos parecen un horrible kluge (además de ser terriblemente inseguro).

¿Hay una manera mejor o más limpia o esta es una idea tan mala para empezar que la discusión sobre el tema no tiene sentido?


¿No puede persistir la información de la sesión en un almacén de datos en el servidor? es decir, archivo XML, base de datos, etc. A continuación, puede pasar simplemente un hash (calculado según algunos criterios que identifican de forma segura la sesión) a una página .NET que puede recoger los datos del almacén de datos utilizando este identificador y completar sus datos de sesión . Todavía significa tener que pasar solicitudes de ASP a ASP.NET a través de un proxy cada vez para asegurar que los últimos datos de la sesión estén disponibles en cada aplicación, pero no sé de una manera alternativa de lograr esto, me temo.


Bueno, finalmente, la mejor idea sería convertir la aplicación ASP a .NET. Creo que eso, sin duda, es evidente. Si la seguridad es una gran preocupación, hay pasos que puede tomar en cuanto al cifrado y el mantenimiento de la integridad de la información de la sesión, para hacerlo más seguro, como algunos cifrados y hash simétricos y otros.


No sé de ninguna manera más limpia para hacer esto en el caso general. Pero tal vez puedas describir más específicamente qué estado tienes que compartir entre los sistemas. Puede haber una solución más limpia en su caso específico. El estado del objeto de sesión no siempre es la mejor forma de mantener el estado.


Tuve que lidiar con el mismo problema. En mi caso, cifré una clave en una cookie y usé la base de datos para cualquier otra información. Escribí la encriptación en .NET e intenté para descifrar la identificación en el lado ASP. Hay algunas rarezas que se ocupan de la cadena base 64 en que ASP no obtendrá la misma cadena que .NET, por lo que puede que tenga que hacer lo que hice y volver a escribir la cadena base 64 en equivalente hexadecimal o algún denominador común más bajo táctica. Es relativamente seguro (excepto un ataque XSS).


Tendría que estar de acuerdo con Wes P ... ¿cuáles son los objetivos a largo plazo? Si el objetivo a largo plazo es migrar la clásica aplicación ASP a ASP.NET, entonces creo que la solución a corto plazo, cualquiera que sea, funcionará. Si el objetivo a largo plazo es mantener la clásica aplicación ASP, sería mejor que optara por una solución más robusta para la gestión de la sesión, similar a lo recomendado por Oglester .