Important Bug Fix Regarding Cookies in Web Connection
January 04, 2009 •
On December 29th, 2008 Web Connection customers started running into problems with West Wind Web Connection. On the morning of the 29th a number of new messages were starting to pour in relating to a problem with Cookies that no longer appeared to work. Specifically many people were reporting that their Session objects were no longer working properly with Session objects just getting lost and resetting on every hit.
It turns out this is a sleeper bug that dates back to older versions of Web Connection (3 and 4 specifically) and is caused by a hard coded Cookie expiration date in the Web Connection core. This was actually fixed in Web Connection 5 and the newly introduced wwPageResponse class, which correctly uses a relatively offset expiration date for cookies. However, even in Web Connection 5 the old classes still exhibit the old behavior with the hardcoded date and a lot of people (including some of my older code) still rely on the older wwResponse, wwHttpHeader and wwScripting classes which all hardcoded the expiration date.
How do I fix the Problem?
A lot of older Web Connection applications broke as a result of this hardcoded Cookie value which happened to expire on December 28th, 2008. The solution to this problem is quite simple actually and there are a couple of approaches you can take depending on which version of Web Connection you are running.
Update to Version 5.41
The easiest thing to do is update to Web Connection 5.41, which has the problem fixed. If you are a registered user of Web Connection 5, this is a free update so there’s no reason not to install this update. You should have already gotten a notification of the new version along with a note regarding this problem along with download information for the new version (same as all other updates – just change the version numbers to 541).
This version has updated all the relevant Cookie definitions and sets them to relative values in the same way as wwPageResponse has done all along. When you install the new version – as you do with all update installs – make sure you RECOMPILE all the Web Connection source code in the Classes folder including the VCX and PRG files.
Manually update the Code
If you are running older versions and you don’t plan on updating or even if you’re running Web Connection 5, you can make a few small changes to source code to fix the problem as well. The affected classes/methods are:
- wwHttpHeader.AddCookie (wwHttpHeader.prg)
- wwScriptingHttpResponse.AddCookie (wwScripting.prg)
The fix in both places is similar and involves changing the tcExpire variable from a hardcoded string to a relative value:
tcExpire=MimeDateTime(DATETIME() + 94170000,.T.)
Here’s the full implementation of the AddCookie() method in wwHttpHeader:
********************************************************************* FUNCTION AddCookie(tcCookie, tcValue, tcPath, tcExpire) ******************************************************* tcCookie=IIF(VARTYPE(tcCookie)="C",tcCookie,"") tcValue=IIF(VARTYPE(tcValue)="C",tcValue,"") tcPath=IIF(VARTYPE(tcPath)="C",tcPath,"/") tcExpire=IIF(VARTYPE(tcExpire)="C",tcExpire,"") IF UPPER(tcExpire)="NEVER" tcExpire=MimeDateTime(DATETIME() + 94170000,.T.) **"Sun, 28-Dec-2008 01:01:01 GMT" ENDIF IF !EMPTY(tcExpire) tcExpire="; expires="+tcExpire ENDIF THIS.oHTML.Write([Set-Cookie: ]+tcCookie+[=]+tcValue+; [; path=]+tcPath+tcExpire+CRLF) ENDFUNC * EOF wwHTTPHeader::AddCookie
Please note, that if you’re running a really old version of Web Connection MimeDateTime() won’t exist (it was added sometime late in the 3.x cycle). In that case you will have to set the date to an explicit value as above and set it to a future date. I recommend not putting this date to far in the future (5 years is about right) and making sure that the mime date string is valid (ie. the date and day of the week are correct). Incidentally, lack of a MimeDateTime() function at the time the original code was written was the reason for hardcoding the cookie date in the first place.
Embarrassing
This kind of bug is quite embarrassing actually – hardcoding values that are bound to change, like dates, is a really bad development practice. Actually I remember precisely how this came about many many years ago. About 10 years ago apparently I was working on that piece of code that set the expiration date and I had issues with certain browsers (Netscape 4.0 specifically) not accepting a cookie expiration date much further in the future. So I ended up experimenting around with different values to find the top end of the range that WAS supported which happened to be somewhere around 10 years (although not exactly), which is the value I set at the time. I figured in 10 years I’d be getting back to this for sure, if the product would even last that long. Well,here we are 10 years later and indeed we’re seeing the fruits of my failure now.
The problem was made worse though by the introduction of a new wwPageResponse class that appropriately fixed the problem going forward by using a sliding date setting, so I never even gave a second thought to the older classes. In fact while a lot of thought went into the refactoring that resulted in the wwPageResponse class, none of the old code got much in the way of code review which is why this problem occurred.
Keeping up to Date
If you’re running an older version of Web Connection you might want to consider updating to the latest version. It’s issues like this as well as security related issues related to the operating system that can often bite you and the currently developed version often fixes many small issues that get addressed transparently in maintenance releases so you never even end up seeing a problem in the first place. Unfortunately this particular bug slipped through the net of checks because it’s in deprecated code, but it’s been updated immediately as soon as the problem became clear and we notified all customers of the problem along with the notification that the new version was available to download with a fix.
Older versions see no updates and inline fixes of any sort so any fixes will have to be applied manually. This isn’t meant as a sales pitch but if you work with a live and active application it might be good to know there’s an active support path that addresses issues as soon as possible.
Phil Hollingworth
January 04, 2009