Others have blogged about this before and his implementation is based on one of Ben Nadel's post which you can see here.
Now, I am a little less lenient on the thought of bots than my friend so I said "Hey why not block them at the Web Server level before it even hits ColdFusion (or any other language)". So while I may opt to block all bots from a web app that I do not care for them to index, he did not quite feel the same. For a website I can see where you may need to be a little more flexible, so I created a set of rules to block most and allow a selected few in.
The rules below allow for bots from Apple, Google, Bing, Yahoo, and Duck Duck Go to pass GO and collect $200. I have included both for IIS URL Rewrite and Apache mod_rewrite.
IIS 7+ using URL Rewrite
Apache using mod_rewrite
But how about them Sessions? Alex, I'll take killing sessions for $400, please.
Well, now with the rules in place blocking bat bots and only allowing a few in, I decided to run a function at onRequestEnd() that takes advantage of a new function since ColdFusion 10 called sessionInvalidate(). Thanks Charlie Arehart for reminding me of it while having a nice discussion on this topic this past CFSummit. As you can see below it is a simple reFindNoCase() on the same expression I used to allow bots in as defined in the RewriteRules.ColdFusion 10+
I tested this using my trusty Fusion Reactor and seeing the session count go up 1 and back down 1 immediately was great, gratifying and ultimately validated my logic!
Please note, this will not change your CFID, CFTOKEN or JSESSIONID values, it simply kills the session each time. If you want new values, then you would need to do sessionRotate() as well but I did not see the need for it since as it will be only execute by bots. Also, if you are using J2EE Session Variables and want its ID reset, you will need to execute getPageContext().getSession().invalidate().
If you do have to support ColdFusion 9 or less, or some other ColdFusion engine, you can use something like Ben's solution and apply the logic to overwrite the SessionTimeout value.
Incidentally, my friend set the SessionTimeout to equal a function which then returned the TimeSpan based on his validations, rather than wrapping his validation around the settings like Ben did. I was originally worried about rewriting the SessionTimeout setting per request (which they both do), which is the reason why I opted for my way instead.
If you need to support another language, you can simply use the rules I have provided and based on how the language you are working with handles sessions, you can create a solution. Hope this helps some of you out, I know for me I rest a little better at night knowing that bots are not causing havoc on my apps and/or sites.
