Мы столкнулись с той же задачей (не весело). Поскольку сеанс Asp.Net и сеанс Asp нельзя разделить, мы использовали комбинацию методов, каждый из которых соответствует конкретной ситуации.
- В некоторых случаях мы использовали куки вместо сессии.
- В других случаях мы настраивали автоматическую публикацию форм таким образом, чтобы, если информация о сеансе пользователя была задана на классической странице ASP, после задания информации о сеансе мы перенаправлялись на страницу Asp.Net, которая считывала параметры строки запроса и те, чтобы установить те же переменные сеанса для Asp.Net. Затем, как только страница Asp.Net установила те же переменные, эта страница перенаправила на любую страницу, на которую ранее указала исходная страница входа. То же самое сработало в обратном порядке.
Итак, во втором сценарии примерный поток изменился бы с:
Пользователь пытается получить доступ к некоторым защищенным
страница контента -> перенаправлена для входа
страница -> вход в систему -> набор информации о сеансе
основано на успешном входе в систему -> перенаправлено
вернуться на страницу содержания.
до
Пользователь пытается получить доступ к некоторым защищенным
страница контента -> перенаправлена для входа
страница -> вход в систему -> набор информации о сеансе
основано на успешном входе в систему -> перенаправлено
на страницу .net, передавая логин
учетные данные и т. д. -> наборы страниц aspx
информация о сеансе, а затем сразу
перенаправляет обратно на страницу содержания.
Мы знали, что это был взлом, но он работал в краткосрочной перспективе, пока мы не смогли преобразовать все сайты.