在上一份工作中，我们有一个经典的ASP应用程序，没人想迁移到ASP.NET。它所做的事情，做得很好。

但是，需要添加一些似乎最适合ASP.NET的新功能。决定让系统成为ASP和ASP.NET的怪异混合体。

我们最大的症结是会话管理，我们共同制定了一种通过表单变量传递会话值的解决方案。我已经与其他通过cookie处理相同问题的人进行了交谈。

两种方法似乎都是可怕的(除了非常不安全之外)。

有没有更好或者更清洁的方法，还是从这个主题的讨论开始毫无意义就这样一个坏主意？

解决方案

我不得不处理同样的问题。就我而言，我将密钥加密为cookie，然后将数据库用于其他任何信息。我在.NET中编写了加密，然后互操作以在ASP端解密ID。处理base-64字符串有些奇怪，因为ASP不会获得与.NET相同的字符串，因此我们可能必须像我那样做，并将base-64字符串重写为十六进制等效或者某些相似的最低公分母战术。它相对安全(保存XSS攻击)。

好吧，最终最好的主意可能是将ASP应用程序转换为.NET。我认为这也许不用多说。如果安全性是一个大问题，则可以采取一些步骤来加密和维护会话信息的完整性，以使其更加安全，例如一些对称的加密和散列，而不要这样做。

在一般情况下，我不知道有任何更干净的方法可以做到这一点。但是也许我们可以更具体地描述系统之间必须共享的状态？在特定情况下，可能会有更清洁的解决方案。
会话对象状态并不总是保持状态的最佳方法。

我们不能将会话数据持久保存到服务器端数据存储中吗？即XML文件，数据库等。然后，我们可以仅将哈希(根据安全地标识会话的某些条件计算得出)传递到.NET页面，该页面可以使用此标识符从数据存储中提取数据并填充会话数据。这仍然意味着每次都必须通过代理将来自ASP的请求传递到ASP.NET，以确保每个应用程序中都有最新的会话数据，但是我不知道实现这一目标的另一种方法。

我必须同意Wes P ...的长期目标是什么？如果长期的目标是将经典的ASP应用程序迁移到ASP.NET，那么我认为我的短期修复方法(无论可能如何)都可以。如果长期保留经典的ASP应用程序，那么最好使用一种更健壮的会话管理解决方案，类似于Oglester推荐的方案。