I recently rolled out beta version of a new application I've been writing, only to discover that there was a bizarre session problem that didn't exist in dev, but does in live.

I've worked it out, but I thought I'd explore it some more. It is a fusebox 5.5 non xml application. The error I had was that as soon as I made a call through a "new" circuit, IE one I hadn't called before ColdFusion would generate a new session ID, and thus invalidate my current active session.

Looking through my application CFC I had this line of code present.

Setting this to true fixed the issue. This is because ColdFusion relies on the CFID and CFTOKEN to maintain the session state. You can either pass these two variables through the URL on every page request, which is a bit messy, or you can use a cookie. It is the variable above that lets the application use cookies on the user's session.

The problem with setClientCookies is that it is persistent, IE it is built for that session, and left on the user's pc, even after the session has expired, or they have left the application. Also some users will accept per-session cookies, but not persistent session cookies.

They are a lot more secure as per-session cookies, as they cannot be duplicated and hacked to spoof a previous user's session, and if you pass the token through the URL it is easy changed.

You could put something like this in your onRequestend function in application.cfc

This will make them per-session. I originally thought that it was something to do with the Fusebox framework, but I had overlooked the simple fact that it was still a new page request, so would be lost. Although this doesn't explain why I wasn't getting this error in my development environment but did in live.

With the continue rollout of IE 8 some issues rise to the top of pile in the way the browser interacts with users. I can see 'why' this next issue occurs, but it doesn't handle the user interaction very well at all.

One of the more significant changes is the way that IE handles security exceptions. The message to the user has been changed to be inversed. Usually a user will look for an 'ok' button, but in this instance 'ok' is the wrong answer (see screenshot).

This pop up happens when the site you are on is serving up non https content on an https URL, IE images and style links that are http://url/image.src rather than https://.

The only work around for this seems to be either having a user manually edit their IE settings, like this:

This isn't exactly reasonable though. The other fix is to change all your content to be https. This is potentially a huge code change depending on how your site works.

I was hoping to find an IE 8 compatibility setting to revert this back to the same handling method as IE 7, but that doesn't seem to exist. If anyone has any ideas feel free to comment!

With the growing phenomenon that is Twitter (don't people remember it from 2004 when it wasn't cool?) There also seems to be a growing trend for random uninvited following. Its only Wednesday and I've had six uninvited 'followings' from people that I have never met, nor share any common associates.

I'm all for social networking – in its proper place, but if Twitter is attracting follow-spam then it's a slippery slope to being blocked altogether. I wonder if they have thought about the whole 'invitation-accept' handshake model of adding contacts that several other social networking sites use.

In the meantime if I don't know you....you're getting blocked.

Until recently I was using a variety of method to stop cross-site scripting attacks, including htmlEditFormat() and a few regular expressions in my frameworks to strip out unwanted characters in returning variables.

I wasn't even aware that there was a 'scriptProtect' setting in ColdFusion until I bumped into it whilst writing a new login CFC recently, so I thought I'd take a closer look.

The first, and most 'global' option is in Cf Admin. If you go to the 'settings' screen there is an option, 'Enable global script protection'. This will enable the option for all sites running on that server. Obviously a bit heavy handed, but I'm not seeing a down side to this at the moment.

Secondly you can set this value in your Application code.

For Application.cfc

Or for Application.cfm

The values for the scriptProtect variable are:

• all
• cgi
• cookie
• form
• form,url
• form,url,cookie
• none
• url

Most of these are obvious really. You can set a delimited list of the scopes you want to protect, or specify 'all' or 'none' for more global covering.

So what actually happens with this option enabled? It essentially replaces certain tags, such as script, object, applet, embed, with the text "InvalidTag". (Functionality I've noticed in BlogCFC as a side note.)

So it translates something like:

Into:

There doesn't appear to be any conflict between setting the value in CF Admin, and your Application scopes, so I'd probably do both, it can't hurt.