Pregunta

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

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

Nuestro mayor problema fue la gestión de la sesión y pirateamos una solución para pasar los valores de la sesión a través de variables de formulario. He hablado con otros que manejaron este mismo problema a través de las cookies.

Ambos métodos parecen ser una mezcla horrible (además de ser terriblemente insegura).

¿Existe una forma mejor o más limpia o es una mala idea comenzar con esa discusión sobre el tema que no tiene sentido?

¿Fue útil?

Solución

¿No puede conservar los datos de la sesión en un almacén de datos del lado del servidor? es decir, archivo XML, base de datos, etc. A continuación, puede pasar solo un hash (calculado en función de 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 llenar los datos de su sesión . Todavía significa tener que pasar solicitudes de ASP a ASP.NET a través de un proxy cada vez para garantizar que los datos de la última sesión estén disponibles en cada aplicación, pero no conozco una forma alternativa de lograrlo, me temo.

Otros consejos

He tenido 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í el cifrado en .NET e intercepté para descifrar la identificación en el lado ASP. Hay algunas rarezas que tratan con la cadena base-64 en que ASP no obtendrá la misma cadena que .NET, por lo que es posible que tenga que hacer lo que hice y reescribir la cadena base-64 a hexadecimal equivalente o algún denominador común más bajo similar táctica. Es relativamente seguro (guardar un ataque XSS).

Bueno, en última instancia, la mejor idea probablemente habría sido convertir la aplicación ASP a .NET. Aunque creo que probablemente no hace falta decirlo. Si la seguridad es una gran preocupación, hay pasos que puede tomar para el cifrado y el mantenimiento de la integridad de la información de la sesión, para hacerlo más seguro, como el cifrado y hashing simétricos y qué no.

No conozco ninguna forma más limpia de hacer esto en el caso general. ¿Pero quizás pueda describir más específicamente qué estado tiene 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 manera de mantener el estado.

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 aplicación ASP clásica a ASP.NET, entonces creo que la solución a corto plazo, cualquiera que sea, funcionará. Si a largo plazo es mantener la aplicación ASP clásica, entonces sería mejor utilizar una solución más sólida para la administración de sesiones, similar a lo que Oglester recomendado.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top