Okay, I know I said I was going to quit thinking about this, but.... I was driving somewhere yesterday afternoon and thought about this invalid sessions issue and the problems with the workarounds I had seen, and I thought that maybe it would help to kill the jsessionid cookie at some point, after seeing what Paul Kenney does in his applicaton.cfc approach.
So, here's the code I am using now, which works to a point (on which more below): <CFTRY> <cfapplication name="THENAME" setclientcookies="Yes" sessionmanagement="yes" clientmanagement="yes" clientstorage="THEDATABASE"> <CFCATCH> <cfapplication name="THENAME" sessionmanagement="yes" setclientcookies="Yes" clientmanagement="yes" clientstorage="THEDATABASE" sessiontimeout="#createtimespan(0,0,00,0)#" > <CFCOOKIE name="jsessionid" value="xxxx" expires="now"> </CFCATCH> </CFTRY> Here's what works about it, and what is still flaky: WHAT WORKS: When a request is made beyond the 60-minutes J2EE session timeout(and by which time the CF session has long ago timed out), the "Session is invalid" error is thrown. This bumps us down to the catch block, where we create CF sessions that immediately time out, and then overwrite the jsessionid cookie with one that expires immediately (which means that it will return the value we have just set for the duration of this request, but will timeout before the next request). It doesn't matter what the value is that we set (but about which more below), because the sole reason we set it is to expire it. The duration of this request will return undefined for any variable within the CF session scope. As long as your visitor has not reached the J2EE timeout in the midst of an operation or sequence that calls session variables to pass things from page to page, etc., everything will appear as normal. Even a return from some non-session-using template to a template in your site that requests a session variable will seem as normal, i.e., it will act as it always does when some earlier session has timed out. THE FLAKY PART: The problem with this workaround is that when a request is made once the J2EE session has timed out, that page will NOT pass on a CF session variable to the next page, since we have gone to so much trouble to time it out. So, if your visitor was in the midst of some sequence where CF session variables carry from one request to the other, you will not only get the first instance of expired session (and which would respond to whatever your normal logic or error trapping is in that case), but also on the NEXT request, there will be no session variable passed, so you could get some oddball wonky results, which we hope your regular logic and error trapping will handle with at least some degree of grace. Then there's the issue of the jsession cookie being set to some phantom value. I haven't even plumbed the depths of what problems that could cause. And then there are the problems of having killed the jsession cookie, which problems I also haven't explored, other than the assumption that if you have a login logic and routine that uses the jsession variable, it would likely mean that you would be sent to the login screen, put in your login info, and be sent right back to the login screen, and it would work as expected this second time, all of which could be confusing. But obviously, anything that calls on the jsession cookie stands to be troubled by this approach. AND YOU'RE WONDERING WHY... I don't set the session timeout to 20 minutes in the catch block, and the reason is that this will lead to the OTHER variety of "Session is invalid" error, the well-documented one that occurs when the CF session timeout is set for longer than the J2EE session timeout, which error I now look back upon with a twinge of nostalgia. BUT I'M USING THIS FOR NOW ANYWAY... ....because this is on my personal site and blog, where the only thing I'm using session variables for is carrying a search term forward through the use of the session variable, and the likelihood of someone taking a 60-minute break in the midst of a search of my weblog archives if fairly statistically low. However, I am the first to say that my fix is not ready for prime time... I would not put a client site using session variables on CFMX7 until this "Session is invalid" thing is solved by CT/MM, which, now that I've gone to all this thought to make a workaround, will likely happen an hour from now! YOU MIGHT ASK... ....why not just switch my search logic to client variables, and I would respond, don't ask. Anyway, this is all even more fun than the Sunday New York Times crossword, and I hope my solution is of use to someone, even with its admittedly flaky side. Best to all, James ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:198599 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
