Session timing out on ASP.NET app after visiting PHP app on same server

Question

I'm working with a client's proprietary ASP.NET app, to which we added a PHP wiki to a subdirectory on the same server. The PHP app authenticates against the cookies that the .NET app uses. This all works fine.

When you login to the .NET app and then visit the PHP app (Dokuwiki), and then visit any page on the .NET app, it reports that the session is expired and asks you to log back in.

Both apps generate cookies, but none of them conflict in name. I stripped out the code in the PHP app that authenticates against the cookie to make sure I wasn't causing the issue with the PHP authentication, but the issue persisted.

With the exception of some front-end things, I have no control over the ASP.NET backend, but I did create a stray .ASPX page in one folder which successfully forces authentication if a user visits it. I created this page in a plaintext editor, not in Visual Studio, so it didn't generate any code behind files. If you visit this page after visiting the PHP app, it does not report the session as having been expired.

My question is that I'm trying to track down what is causing this behavior, first, and then looking at options for correcting it. I'm sorry for the dearth of more technical detail -- as mentioned, I only have limited access to the client's app. Any help would be very appreciated, and if any more information is needed to help troubleshoot, I'll gladly provide what I can.

Answer 1

Hi hellbox--

I've had similar problems with classic ASP sites running on the same server as ASP.NET sites.

I'm usually able to fix the problem by creating 2 application pools under IIS: one for the ASP sites and one for the ASP.NET sites.

Do you have access to the server's IIS manager, or can you contact someone who does? If so, create 2 separate app pools: one for PHP sites and one for ASP.NET sites. Then move each site into the appropriate app pool. Restart IIS if you can, and then see if anything's changed.

Hope this helps!

Answer 2

I called in the original developer to troubleshoot this. He solved it by switching from SQL Server based session state to "In Process." That seems to have taken care of it.