客户端使用经典ASP来登录到他们基于Web的后台。在经典ASP和ASP.Net之间共享登录系统
我已经写了一个新的ASP.Net应用程序包含在后台，我需要利用已经存在的登录系统，这样当他们登录时，他们不需要再次登录在新的ASP.Net应用程序中。
登录名和密码以明文形式存储在SQL Server数据库中，我可以从我的ASP.Net应用程序访问它。
什么是整合这些系统的有效方法？
我当前最好的想法是： 在我的ASP.Net应用程序的链接中，我使用它们的用户标识和查询字符串中的散列密码+通用密码链接到“网关”登录页面。然后，我将它与数据库中用户的密码进行比较......但问题是，如果此查询字符串被截取，它可以用于访问asp.net网站，而无需知道用户名和密码......
我很可能忽略了简单的事情。
我认为你的想法是在正确的道路上。
正如你可能已经知道的那样，经典的asp和asp.net不能共享相同的会话状态，所以你确实需要有一种机制来从一个登录到另一个。
我会做的是：当有人登录时，创建一个唯一的GUID，保存在该用户的数据库中。当您从一个站点跳到另一个站点时，将该GUID传递到查询字符串中。当您尝试将它们自动登录到其他站点时，请查找该GUID并查看它是否与任何人连接。如果是，请登录他们。
这样，你不传递任何一个用户可以猜测或解密。
传统ASP系统如何保持登录状态？ “背驮式”这将是你最好的选择，迄今为止。
我工作过的所有传统ASP系统都使用cookies来跟踪认证信息，所以只需读取这些信息并与您可以访问的数据库进行比较。
由于信息存储在传统的ASP会话，可能你一个“重定向页”添加到事物的传统的ASP一侧是“入口”到新的模块，并导致该写有用的数据作为cookie，或触发一个POST到您的首页？通过使用cookie或POST请求，可以最大限度地减少您对URL“被劫持”的担心，从而允许某人无需用户名/密码进入ASP.net站点。
他们使用会话 - 并且不能在ASP和ASP.Net之间共享（据我所知）。 望着饼干，当我登录到他们的管理系统中，我得到了一个包含废话一些字符串“DBHPNPCDKCJHOMHDPFOHEDPA”称为“ASPSESSIONxxxxxxxxxxx”会话的cookie。 所以捎带饼干似乎没有问题。 – Kjensen 2009-05-28 15:54:29
我同意Rob的观点，重定向方案可能是你最终的结果，因为.NET无法直接检查ASP站点的会话状态。这种方法也可以处理不同领域的优势，但要确保安全性并非易事。 如果你关心安全性，你应该非常小心你如何验证/无效在站点之间传递的数据。您不想最终获得可以通过猜测或重播URL来登录的系统。例如，SAML重定向在重定向的每一侧使用证书来保证传递的数据安全。 ASP和ASP.NET之间 – JohannesH 2009-05-28 17:07:14
共享会话状态：http://msdn.microsoft.com/en-us/library/aa479313.aspx – 2009-05-28 20:06:47
难道你不能通过表单而不是通过Querystring提交吗？这将消除在URL中被拦截的可能性。
如果拦截是一个严重的问题，那么你需要通过HTTPS运行该网站。否则，使用密码散列的UserID + Nonce相当强大。
或者你可以得到的ASP应用程序添加一个GUID会话cookie登录后已经来达到的和商店，GUID在数据库表。您的ASP.NET可以从cookie中查找GUID以查看登录是否成功。如果在表中包含ASP会话cookie值，则可以合理确定当前的ASP会话与创建GUID时使用的会话是相同的。
你是理所当然的担心MITM攻击类型，可能是通过DNS缓存中毒或相似。根据您的情况，通过向跨应用程序边界传递的登录标记添加时间约束，可能足以减轻此潜在影响。
的“GUID数据库的方法”是我在过去成功地使用自己，无论是传递两个应用程序之间的用户共享同一个认证数据库，也为“密码重置邮件”类型的场景。您可以通过在记录上添加一个指定添加GUID的日期的额外列，并修改应用程序代码以仅登录小于x分钟/小时/天的GUID验证字来“过期”。
另一种可能是通过连接类似，以避免在数据库附加字段：
UserId + [Value representing current time to nearest x minute/hour /day] + Salt
..哈希处理，然后再复制你对其他应用程序算法和比较两个生成的值。
在一般情况下，我认为你提出的解决方案是合适的问题。这当然不是太复杂。
如果你把他们需要超时查询字符串的哈希值，即你还追加了日期和时间到期时，以及沿太发送。当然，他们仍然可以使用它，但至少它会超时。 – PQW 2009-05-28 15:45:27