PHP和ASP.NET之间在同一IIS服务器上的通信

Question

我们有以下设置：

-Windows 2008 R2 Standard。

-ASP.NET Web应用程序部署在Microsoft IIS 7.5 Web服务器上。

-PHP版本5.4.21非线程32位版本

-WISP（Windows，IIS，SQL Server / Express和PHP）堆栈和ASP.NET Web应用程序HTTPS（SSL）

我们最终将在同一IIS服务器上部署ASP.NET Web应用程序和PHP Web应用程序。

用户将首先登录ASP.NET Web应用程序，但我们希望用户能够轻松地在ASP.NET Web应用程序和PHP Web应用程序之间来回导航。

我们计划在ASP.NET Web应用程序端和PHP应用程序端实现基于REST的Web服务。

用户登录框架仅在ASP.NET Web应用程序端（对于那些熟悉ASP.NEt技术的人，我们使用的是ASP.NET成员资格框架）。

正如我之前提到的，用户将首先登录到ASP.NET Web应用程序，但我们希望用户能够轻松地在ASP.NET Web应用程序和PHP Web应用程序之间来回导航。 / p>

我们是否必须在用户从ASP.NET端导航到PHP端时重新验证用户，反之亦然？

当用户从ASP.NET端导航到PHP端，反之亦然时，是否足够合理地安全地传递登录cookie（“安全令牌”）？

请随意建议上述方法的替代方法（例如，有些人告诉我使用Memcached技术在ASP.NET Web应用程序和PHP Web应用程序之间共享会话信息.Memcached技术比使用Web更好吗？服务？）

Answer 1

我成功地实现了与你描述完全相同的东西，但方向相反。用户将在PHP端（现有的遗留站点）进行身份验证，我们只需通过cookie获取安全令牌，然后只读取相同的数据库以确保令牌仍然有效。对于每天支持数百名普通用户的网站而言，工作没有问题。在我们的例子中，PHP服务器和ASP.NET服务器实际上甚至托管在不同的设施中。

请注意，使用基于cookie的安全令牌（会话令牌）很常见。只要域从浏览器的角度来看没有变化，或者在进行身份验证时正确设置cookie的路径，您就不必做任何额外的事情来让用户浏览器维护并向您发送令牌。