我想告诉你，我是怎么做到的.

这两个应用程序都访问一个 MySQL 数据库并访问一个会话"表，该表由一个 Guid、用户的 ID 和一个确认字符串(我猜我在其中编码了 IDUser，不知何故)和一个日期.>

会话仅由 PHP 应用程序启动(因为 PHP 应用程序仍然是主应用程序).新会话将在日志表中产生一个新条目.PHP 应用程序中的每个链接，即到 ASP.Net 应用程序的链接都包含 GET 参数，包含 Guid 等.

ASP.net 应用程序检查 GET 参数并在 ASP.Net 会话中设置 IDUser，如果 GET 参数指向现有会话.

指向 PHP 应用程序的链接使用相同的技术.

(还有其他事情需要考虑，比如超时或注销，但也可以处理)

总而言之，我会说我的方法很有用，并且自部署(一年多前)以来没有任何客户抱怨

My company took some old php application over. Due to our preference to ASP.net and to the lack of any documentation from the previous developer, we do not want to spend much resources on developing in PHP. For implementing new features, we will create an Asp.net application that has the same look to the user. We want to develop a kind of 'coexisting' web application. Therefore we must share sessions between an PHP and an Asp.net webapplication project, because there is a usermanagement involved with an existing MySQL database.

(e.g. link 'A' directs to the PHP website, and link 'B' directs to the asp.net application)

How can we share the session between and PHP and an asp.net application?

And does anyone have a hint for this 'coexisting' thing, that might be useful in development?

Edit: IIS 6 would be our targeted server, altough IIS 7.5 would also be an option

I want to tell you, how I ended up doing it.

Both applications access a MySQL database and access a "session" table, which consists of a Guid, the ID of the user, and a confirmationString (I guess I encoded the IDUser in it, somehow) and a date.

Sessions are only started by the PHP application (due to the fact, that the PHP application is still the main application). A new session will result in a new entry in the log table. Every link in the PHP application, that links to the ASP.Net application contains GET-Parameters, containing the Guid etc.

The ASP.net application checks for the GET-Parameters and sets the IDUser in the ASP.Net Session, if the GET-Parameters point to an existing session.

The links pointing back to the PHP application use the same technique.

(There are also other things to consider, like timeouts or logouts, but that can be handled as well)

All in all, I'd say that my approach is useful and none of the customers complained since the deployment (over 1 year ago)