tags:

views:

787

answers:

5

In a previous job we had a classic ASP application that no one wanted to migrate to ASP.NET. The things that it did, it did very well.

However there was some new functionality that needed to be added that just seemed best suited to ASP.NET. The decision was made to allow the system to become a weird hybrid of ASP and ASP.NET.

Our biggest sticking point was session management and we hacked together a solution to pass session values through form variables. I've talked to others that handled this same problem through cookies.

Both methods seem a horrible kluge (in addition to being terribly insecure).

Is there a better or cleaner way or is this just such a bad idea to begin with that discussion on the topic is pointless?

+4  A: 

I have had to deal with the same problem. In my case, I encrypted a key into a cookie and used the database for any other information. I wrote the encryption in .NET and inter-op'd to decrypt the id on the ASP side. There is some weirdness dealing with base-64 string in that ASP will not get the same string as .NET, so you may have to do as I did and rewrite the base-64 string to hex equivalent or some similar lowest-common-denominator tactic. It is relatively secure (save a XSS attack).

Greg Ogle
The Base64 algrothim is very stable and ASP has no way to handle Base 64 natively. Hence whatever algorithm you were using before was just simply bugged.
AnthonyWJones
The Request.Cookies in ASP does some encoding that is not done in ASP.NET
Greg Ogle
+1  A: 

Well, ultimately the best idea would probably to have converted the ASP app to .NET. I think that probably goes without saying though. If security is a big concern there are steps you can take as far as encryption and maintaining the integrity of the session information, to make it more secure, such as some symmetrical encryption and hashing and what not.

Wes P
+1  A: 

I dont know of any cleaner way to do this in the general case. But perhaps you can describe more specifically what state you have to share between the systems? There may be a cleaner solution in your specific case. Session object state are not always the best way of keeping state.

JacquesB
+5  A: 

Can you not persist session data to a serverside data store? ie XML file, database etc. You could then pass just a hash (calculated based on some criteria that securely identifies the session) to a .NET page which can the pick the data up from the data store using this identifier and populate your session data. It still means having to pass requests from ASP to ASP.NET through a proxy each time to ensure the latest session data is available in each app but I don't know of an alternative way to achieve this I'm afraid.

Luke Bennett
+1  A: 

I would have to agree with Wes P ... what are the long-term goals? If the long-term goal is migrate the classic ASP application to ASP.NET then I think I short-term fix, whatever it may be, will work. If the long-term is to keep the classic ASP application then you would be better off going with a more robust solution for session management, similar to what Oglester recommended.

mattruma