Rick Strahl's Weblog
Rick Strahl's FoxPro and Web Connection Weblog
White Papers | Products | Message Board | News |

Important Bug Fix Regarding Cookies in Web Connection


5 comments
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.

Posted in:

Feedback for this Weblog Entry


Problem with FileTime



Phil Hollingworth
January 04, 2009

Hi Rick

Just installed 5.41 and recompiled class PRG & VCX and now get this error:

Error Message: File 'filetime.prg' does not exist. Error Number: 1 Running Method: getpageclassinfo Current Code: REPLACE Filename WITH lcPhysical, SourceFile WITH lcSourceFile, Class WITH lcClass, GeneratedClass WITH lcGenerated, SavedTime with FileTime(lcSourceFile) Current Code Line: 1609 Exception Handled by: Wr08web2_process.OnError()

This error only started after the upgrade and I found the following thread on the boards relating to it: http://www.west-wind.com/wwThreads/default.asp?Thread=2JQ0VOSQY&MsgId=2JQ0YEJJJ

re: Important Bug Fix Regarding Cookies in Web Connection



Gordon Norris
January 05, 2009

Hi Rick,

Ironically I've amended this code on several occations to implement custom behaviour. Due to the fact that I do not use cookies that are set to NEVER I didn't worry about. I'm sorry I never brought this to your attention.

I am slightly concerned though, I've always manually fixed projects due to some bad development practices I do. Unfortunately to get things working I've always hacked the base classes. I should really report things I need but getting the job done always come first. Its always a problem with version updates (bug fixes etc) I have to analyze what has changed.

I don't want to go round my apps to fix this and I cannot update them easily. Can I ask whether or not the bug affects my apps if I do not use NEVER cookies? I've had no reports of problems from customers so far.

Many Thanks

Gordon

re: Important Bug Fix Regarding Cookies in Web Connection



Nelson
January 05, 2009

Since we are talking about hard to find bugs, I don't know if you already fixed this or not, but the class.method wwEval.MergeText has a bug when the text that is being evaluated crashes. It is this line:

lcResult = THIS.cErrorResult

But the property cErrorResult doesn't exist. It should be changed to cErrorMessage

Additionally, in my project, I also included that message in the output to the screen, so that I know what the problem was. Right now it only says "Invalid Expression" or "Error", which is not very helpful.

re: Important Bug Fix Regarding Cookies in Web Connection



Rick Strahl
January 05, 2009

@Nelson - thanks. Actually that should be TRANS(this.vErrorResult). However, that code is never hit in typical Web Connection applications. It's for a special case when non ASP parameters are passed in which isn't done at least not natively in the framework.

If you find bugs like this it's best to report them on the message board when you find them in the bug reports section (or anywhere appropriate for that matter). That way they'll get fixed right away.

re: Important Bug Fix Regarding Cookies in Web Connection



Rick Strahl
January 05, 2009

@Phil - you have to re-compile your code after installing new updates. Please check the Web Connection documentation on how to recompile thouroughly.

The issue in most cases is that the FXP files on your system are newer than the PRG files from the update, so unless you delete the FXP files or recompile the PRG files explicitly the updates won't be active. Note that compiling the EXE also doesn't update the FXP files, so unless you run the EXE compiling the project doesn't do anything for updating the FXP files to the latest version.

 
© Rick Strahl, West Wind Technologies, 2003 - 2024