我有一个asp经典网站，我想添加一些新代码。我想开始用.net编码。有没有一种简单的方法可以做到这一点。
我在想一个调用我的.net页面的iframe，但是如何分享我的用户需要登录我的asp经典网站。
如果我使用iframe，那么分享我的用户的最佳技巧是什么。我在考虑在查询中传递加密信息：test.com?users=[mycrypteduser]。但是我该如何加密呢？
答案 0 :(得分：5)
我非常确定您可以在单个Web项目中混合使用aspx和asp文件。因此，创建web-proj，然后将现有的网站文件放入其中（从VS中）。然后，慢慢开始将您现有的站点重构为aspx，然后逐页，然后以aspx的形式创建新页面。
在这种方法中使用IFRAME将是一项人们可能预期的更多工作。但是，无论如何，您都需要相互信任彼此认证的会话才能解决2个不相关网站的问题 - 这主要是通过那些在后台将这些信息传递给彼此的网站解决的，而不是直接参与浏览器。您需要能够更改两个站点的代码（因此，您必须拥有这两个站点）。所以，如果你想走这条路，通常就是这样做的：
用户登录您的asp网站
您的ASP站点在您的ASP.NET站点上调用Web服务，并通知它用户将在查询中使用特定的一次性身份验证令牌，并且应该信任它。这里的重点是：Web服务必须受到身份验证机制的良好保护（否则您将面临巨大的安全问题）;提到的auth-token应该在它使用一次后才会过期（否则，您将打开您的asp.net网站进行滥用）。通常，您的ASP应用程序将使用以下签名调用ASP.NET上的服务：string GetAuthToken(string username)。 ASP.NET应用程序应将此信息存储为数据库中的记录：用户名，一些随机和唯一的字符串值（例如guid），创建时间（精度至少为一秒）和使用的时间。
您的ASP应用程序从ASP.NET应用程序收到一次性身份验证令牌。
您的ASP应用程序需要将此标记包含在框架上使用的URL中，以及ASP.NET网站上的页面。
然后，您的ASP应用程序将向浏览器提供带有框架的页面。
浏览器开始显示页面，然后显示框架到外部asp.net页面
浏览器请求asp.net url，其中包含auth-token
ASP.NET站点接收请求，并假定auth令牌存在且有效;否则，例外。有效令牌是：从不使用（在步骤2中提到的db中使用的时间），以及有效（它在db中的存在）。当接收页面验证此令牌时，它会立即将其检查为已使用。将此逻辑作为一个原子操作（例如存储过程，如果您使用的是MS SQL Server）是最好的。这样，您可以在一个步骤中执行get-token和mark-token。此网址必须是匿名的;你必须在这个站点上拥有forms-auth，并且匿名用户应该可以访问这个特定的处理程序。如果您不喜欢发出异常，那么可能会创建一个HttpModule，它会检查每个请求，并仅对那些匿名并且包含auth-token的行为（通过验证令牌，然后，适当时，中断请求或让它执行）;这样，您的框架页面不必关心身份验证，但它也必须是form-auth保护。我个人会这样做（http模块）。此外，如果您确定此处的步骤1和步骤2之间会经过相对较短的时间段（例如最多几秒），那么执行会在令牌验证逻辑中包含令牌过期（验证时间不得晚于token-create-time +一些秒数，例如30） - 只是为了额外的安全性。否则，如果你没有实现过期 - 想象一下今天登录的用户，它会生成这个永不过期的令牌，并且恶意用户会以某种方式获取令牌字符串。然后，如果经过身份验证的用户从未访问过具有asp.net框架的页面，那么即使在真实用户关闭其帐户之后，该令牌也可以在其发布之后的几天，几个月，几年内使用。你不想要这种风险。如果登录页面没有重定向到带有框架的页面，则改为从该页面进行服务调用（每个会话一次）。理想情况下，令牌应在创建后最多30秒到期。
如果令牌有效，则验证令牌的ASP.NET应用程序部分将负责发出forms-auth cookie。你会在那里找到大量的例子;关键字：FormsAuthentication，创建cookie，验证用户。确保除了将cookie插入响应（默认情况下由FormsAuthentication模块完成）之外，您还可以立即设置当前/特定请求的标识，直到您这样做，您的请求仍然是被认为是匿名的。如果你不这样做（人们这样做，但我不认为这是必要的），你将不得不重定向该请求（这将迫使浏览器发送auth-它刚刚在302响应中收到的cookie。
最后，您的框架页面会收到用户签出的确定内容，并且可以查看该页面生成的内容。您的页面将HTML流式传输到浏览器，浏览器会在框架中显示该内容。
请注意，您将不能够在页面和框架之间进行任何类型的客户端脚本（javascript）（安全原因），这将是我和我的另一种方式＃39;而是将asp与asp.net文件混合（并将asp部分缓慢升级到asp.net），前提是在其他与业务相关的方面有意义。
注意与出站请求相关的共享托管问题。有些主机阻止所有出站流量;所以，如果您的asp应用程序处于这样的环境中，您将无法对asp.net进行web服务调用。如果你有asp应用程序通过互联网进行其他/不相关的http呼叫（例如，它与第三方Web服务进行对话），那么你很好（它会工作）;否则，以某种方式测试这个，因为你永远无法确定。此外，即使您的站点在您自己的环境中运行，公司通常也会安装出站防火墙，因此您可能需要为此请求例外。
请记住，页面刷新不会成为问题，并且您不需要为每个经过身份验证的会话进行一次get-token调用。这是因为浏览器在第一帧加载后会有来自asp.net站点的auth-cookie，并且令牌（即使存在于后续帧url中）也不会被验证（请记住，模块会在匿名时验证令牌）仅限会话;见步骤8）。
请考虑调整两个站点之间的Cookie过期设置。想象一下asp.net auth cookie在asp auth cookie到期之前到期：用户重新加载页面，iframe显示asp.net上的登录页面 - 丑陋。所以，你的asp.net auth cookie应该设置为比asp auth cookie更长的时间（无论你设置多长时间，你都不会解决问题，因为它设置cookie是错误的不会过期很长时间，例如7天，或者理论上可能的是，你的asp网站的用户将在他们看到它之后没有触摸带有框架的页面，并且你的asp。网络cookie将过期）。所以，做这样的事情可能：设置asp.net auth cookie在20/30分钟到期（其中一个是默认的超时值）。然后，让asp应用程序知道此超时值。因此，更正我之前每次会话的一次接听电话的陈述。相反，每当您知道asp.net cookie已经过期或可能很快到期时，让asp调用get-token服务。换句话说，跟踪您为每个用户进行最后一次获取令牌调用的时间，如果自上次获取令牌调用后15分钟（例如，asp.net cookie在20中过期）已经过去，请再次进行，更改框架网址，一旦现有的asp.net cookie到期，该框架将被验证（在此示例中，此时间约为5分钟）。
我一直回来编辑这个答案:)所以，cookie过期问题 - 假设asp.net cookie在20分钟后到期，我告诉你每隔15分钟在框架上设置网址，同时我也告诉你使令牌在30秒内到期 - 所以，这两件事情是相互矛盾的。嗯，我想知道这里有什么最好的解决方案......也许将get-token设置为更接近asp.net cookie到期（例如，在18分钟，但仍然小于20），并设置令牌有效，我不知道，3分钟）。这将导致18 + 3 = 21与asp.net cookie到期重叠。这一切都是因为用户已经拥有了asp.net cookie。因此，在第一个cookie发布后18分钟，他们访问带有框架的页面，页面决定获得另一个令牌。这会在asp.net网站上启动令牌代码，并使用新令牌设置iframe网址。但是，由于现有的asp.net cookie仍然有效，新的令牌甚至都不会被验证（请记住模块只验证带有令牌的匿名请求？否则，如果你在每次请求时都有这么多的db命中），因此新令牌不会立即使用。最终，asp.net cookie将过期（2分钟内），新的令牌将被验证。如果这是一个问题（如果我省略了一些基本上导致框架中显示登录页面的用例），那么也许你可以实现一些其他机制来保持这些cookie：可能在asp的登录页面添加代码。 net来查找ReturnUrl中的令牌（解码，然后加载到NameValueCollection中，然后将其作为正常的查询字符串查找），并且可能会回复到asp站点，这会发信号通知它在帧到来时重新请求令牌返回（我的意思是，将框架登录页面重定向，仅在这种情况下，返回到asp站点的特殊asp脚本，它将重新请求令牌，然后将帧重定向回asp.net令牌。
我告诉过你这很重要。也许有一个涉及所有这一切的标准。查看OAuth（http://oauth.net/）和OpenID（http://openid.net/）;这些方法类似于StackOverflow提供的SO帐户（谷歌，雅虎等）的替代登录。但是，这意味着您实际上将用户发送到asp.net站点进行登录，然后返回显示asp.net站点内容的页面。也许你可以将它与我建议的webservice调用结合起来（get-token ws，将带有令牌的顶部窗口重定向到asp.net，asp.net将进行身份验证并重定向回来，然后将显示带有框架的页面）。但是，您仍然存在cookie过期问题，因为您需要始终能够从asp.net站点获取内容（而StackOverflow，例如，在登录期间仅代表我与Google进行一次会话，并且在会话），但不是我发送给你的那个凌乱的iframe重定向路径，也许你可以每15分钟重复登录到asp.net网站例程（获取令牌，重定向，验证令牌，重定向回来）。如果你在整个asp站点级别每15分钟执行一次，那么你应该没问题 - 在大多数情况下，用户甚至不会注意到这一点，因为这些重定向会很快。
对不起，如果这是一个困难的阅读。不过，我希望它有所帮助。如果是，则+1：）
答案 1 :(得分：1)
您可以创建一个新的ASP.NET Web应用程序，并拉出所有经典ASP页面。然后在部署时，ASP.NET Web应用程序将覆盖您的经典ASP。
如果您使用某种集成身份验证，ASP和ASP.NET页面都可以访问相同的身份。如果您在ASP应用程序中创建了自己的身份验证层，则需要在ASP.NET中重新创建它（例如，创建读取/写入ASP页面正在使用的相同身份验证cookie的类）。
然而，从长远来看，这将在ASP和ASP.NET之间引入一些开发摩擦切换，所以如果你计划将整个应用程序从经典ASP逐步转换为ASP.NET，我真的只会建议这种方法。
答案 2 :(得分：0)
您可以使用NSession http://nsession.codeplex.com/一个开源项目，其目标是允许ASP Classic以与ASP.NET访问它们相同的方式访问ASP.NET进程外会话存储，从而共享会话使用ASP.NET进行状态。
我试过了它确实有效。
快乐编码!!
答案 3 :(得分：0)
当我遇到这个问题时，我发现最好的解决方案通常是使用.NET作为Web服务，并在ASP页面中使用HTTPRequests将数据提取到ASP页面。
与ASP和Classic ASP共享会话时，最常见的方法是不在ASP中使用会话，并且通常使用Cookie，数据库Cookie实际进行会话验证。