Подтвердить что ты не робот

Классическая интеграция ASP и ASP.NET

В предыдущем задании у нас было классическое приложение ASP, которое никто не хотел переходить на ASP.NET. То, что он сделал, это очень хорошо.

Однако была добавлена ​​какая-то новая функциональность, которая должна была быть добавлена, которая просто казалась наиболее подходящей для ASP.NET. Было принято решение разрешить системе стать странным гибридом ASP и ASP.NET.

Наша самая большая точка привязки - это управление сеансами, и мы взломали решение для передачи значений сеанса через переменные формы. Я говорил с другими, которые обрабатывали эту проблему с помощью файлов cookie.

Оба метода кажутся ужасным kluge (в дополнение к ужасно небезопасным).

Есть ли лучший или более чистый способ или это просто такая плохая идея, чтобы начать с того, что обсуждение темы бесцельно?

4b9b3361

Ответ 1

Можете ли вы не сохранять данные сеанса в хранилище данных на сервере? т.е. XML файл, базу данных и т.д. Затем вы можете передать только хеш (рассчитанный на основе некоторых критериев, которые надежно идентифицируют сеанс) на странице .NET, которая может отображать данные из хранилища данных с использованием этого идентификатора и заполнять данные сеанса, Это по-прежнему означает необходимость передавать запросы от ASP к ASP.NET через прокси каждый раз, чтобы обеспечить доступность последних данных сеанса в каждом приложении, но я не знаю об альтернативном способе этого. Я боюсь.

Ответ 2

Мне приходилось иметь дело с одной и той же проблемой. В моем случае я зашифровал ключ в файл cookie и использовал базу данных для любой другой информации. Я написал шифрование в .NET и inter-op'd для дешифрования идентификатора на стороне ASP. Существует какая-то странность, связанная с базой-64-строкой в ​​том, что ASP не получит ту же строку, что и .NET, поэтому вам, возможно, придется сделать то же, что и я, и переписать строку base-64 в шестнадцатеричный эквивалент или какой-то аналогичный наименьший общий знаменатель тактика. Это относительно безопасно (за исключением атаки XSS).

Ответ 3

Ну, в конечном итоге, лучшая идея, вероятно, превратила бы ASP-приложение в .NET. Я думаю, что это, вероятно, не имеет значения. Если безопасность вызывает серьезную озабоченность, есть шаги, которые вы можете предпринять, чтобы шифровать и поддерживать целостность информации о сеансе, чтобы сделать ее более безопасной, например, некоторое симметричное шифрование и хеширование, а что нет.

Ответ 4

Я не знаю, какой способ сделать это в общем случае. Но, возможно, вы можете более конкретно описать, какое состояние вы должны разделить между системами? В вашем конкретном случае может быть более чистое решение. Состояние объекта сеанса не всегда является лучшим способом сохранения состояния.

Ответ 5

Я бы согласился с Wes P... каковы долгосрочные цели? Если долгосрочная цель заключается в переносе классического ASP-приложения на ASP.NET, то я думаю, что краткосрочное исправление, каким бы оно ни было, будет работать. Если в долгосрочной перспективе нужно сохранить классическое приложение ASP, вам лучше будет работать с более надежным решением для управления сеансом, как это рекомендовано Oglester.