Some gotchas with sharing ASP and ASP.Net Cookies

Blog

I recently had a project that was in the process of migrating from ASP to ASP.Net.  The site was a decent size, so we were moving part by part into ASP.Net.  The authentication forms were still in ASP.  There was the ability for users to save their user names and some other information by selecting a check box with the login form.  Pretty simple stuff, except that the cookie was storing it unencrypted.  The security folks didn’t care for that, so it off the drawing board to draw up a design to encrypt the cookie.  Should be easy right?  Well, actually, it is pretty easy, once you get around a few gotchas

First off, we are going to move from the ASP authentication forms to ASP.Net at some point in the future.  They don’t want users to have to do anything special for this, and the existing persisted cookie should be used.  Okay, so ASP.Net needs to read the same cookie.  Not a problem.  Oh, and we may need to write to the cookie from both ASP and ASP.Net until everything is moved to .Net.  Hmmm, okay, still using the same cookie.  Not a problem.  And the encryption mechanism should be the same, obviously, since we will be using the same cookie later.

Well, as I was putting together a prototype I found out the following:

  1. While ASP automatically performs a URLEncode and decode on the values and keys as they are written to a cookie, ASP.Net does NOT.  This one caught me by surprise as the encrypted values had extra characters in it one it was written to the cookie from ASP that I didn’t see in the value being written while debugging.
  2. By default ASP will write a cookie using the name of the web application.  ASP.Net uses the machine name as the cookie name.  This one also threw me as ASP wrote the cookie and ASP.Net could read it, but then when I tested a page from ASP.Net to write the cookie the values I wrote didn’t show up in the ASP page that read the values.  There were then two separate cookies.  DOH!

So, what do we do about these?  Well:

  1. Code that writes or reads cookies in our ASP will not do encoding or decoding of the keys and values.  This is good because ASP doesn’t have a URLDecode function intrinsically.  ASP.Net will do a URLEncode and URLDecode with each key and value it writes so that it can read and write the same values ASP has done correctly.
  2. Cookie.Path.  Since we are migrating to ASP.Net from ASP, I just set the cookie.path in ASP.Net to be the application name.  In my case it’s the root website, so we set it to a value of “/”, which really doesn’t make a difference from what ASP comes up with; however, if the site was say at http://server/app/ then ASP.Net would just make a cookie called Server and ASP would make one called “app”.

I got the whole thing working and am working on the design documents.  It uses DES encryption, if you’re wondering.  I created a component in .Net that does the encryption and decryption and then registered that component so that a COM Callable Wrapper can use it at runtime.  This way both ASP and ASP.Net use the exact same component for the encryption and decryption.  Later, when ASP is phased out we can just deregister the component and remove the type library creation from the build as clean up.

Thoughts?  Did I miss something obvious?