SessionInvalidate

[JamesHookerMSO]

The SessionInvalidate backport attempts to use a function that was only introduced in CF10, in particular, lines 72-73 in cf10.cfm.

lc.sessionTracker = CreateObject("java", "coldfusion.runtime.SessionTracker"); lc.sessionTracker.cleanUp(application.applicationName, lc.sessionId);

This causes an error when calling SessionInvalidate in CF9 and below.

[misterdai]

This is a strange one. The cleanUp method is something I used on CF8/CF9 in my CFTracker project without a problem (unless my memory is corrupt :confused:) and I didn't seem to change it when I added CF10 support to the project.

Can you provide the error stack that you're encountering?

[JamesHookerMSO]

Thanks for the reply.

Here's the error stack. Note that the application has a name set, and the value in Session.sessionid also has a value.

My CF version is 9,0,2,282541.

The following information is meant for the website developer for debugging purposes.
Error Occurred While Processing Request
The cleanUp method was not found.

Either there are no methods with the specified method name and argument types or the cleanUp method is overloaded with argument types that ColdFusion cannot decipher reliably. ColdFusion found 0 methods that match the provided arguments. If this is a Java object and you verified that the method exists, use the javacast function to reduce ambiguity.

The error occurred in /media/sf_Development/websites/www.test.local/index.cfm: line 4
2 : <cfscript>
3 :     sessionTracker = CreateObject("java", "coldfusion.runtime.SessionTracker"); 
4 :     sessionTracker.cleanUp(application.applicationName, session.sessionid);
5 : </cfscript>
Resources:
Check the ColdFusion documentation to verify that you are using the correct syntax.
Search the Knowledge Base to find a solution to your problem.
Browser     Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
Remote Address      10.0.5.86
Referrer    
Date/Time   18-Jul-14 09:01 AM
Stack Trace
at cfindex2ecfm1635164039.runPage(/media/sf_Development/websites/www.test.local/index.cfm:4) 

coldfusion.runtime.java.MethodSelectionException: The cleanUp method was not found.
    at coldfusion.runtime.java.ObjectHandler.findMethodUsingCFMLRules(ObjectHandler.java:383)
    at coldfusion.runtime.java.JavaProxy.invoke(JavaProxy.java:110)
    at coldfusion.runtime.CfJspPage._invoke(CfJspPage.java:2360)
    at cfindex2ecfm1635164039.runPage(/media/sf_Development/websites/www.test.local/index.cfm:4)
    at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:231)
    at coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:416)
    at coldfusion.filter.CfincludeFilter.invoke(CfincludeFilter.java:65)
    at coldfusion.filter.ApplicationFilter.invoke(ApplicationFilter.java:366)
    at coldfusion.filter.RequestMonitorFilter.invoke(RequestMonitorFilter.java:48)
    at coldfusion.filter.MonitoringFilter.invoke(MonitoringFilter.java:40)
    at coldfusion.filter.PathFilter.invoke(PathFilter.java:94)
    at coldfusion.filter.LicenseFilter.invoke(LicenseFilter.java:27)
    at coldfusion.filter.ExceptionFilter.invoke(ExceptionFilter.java:70)
    at coldfusion.filter.ClientScopePersistenceFilter.invoke(ClientScopePersistenceFilter.java:28)
    at coldfusion.filter.BrowserFilter.invoke(BrowserFilter.java:38)
    at coldfusion.filter.NoCacheFilter.invoke(NoCacheFilter.java:46)
    at coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:38)
    at coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22)
    at coldfusion.filter.CachingFilter.invoke(CachingFilter.java:62)
    at coldfusion.CfmServlet.service(CfmServlet.java:201)
    at coldfusion.bootstrap.BootstrapServlet.service(BootstrapServlet.java:89)
    at jrun.servlet.FilterChain.doFilter(FilterChain.java:86)
    at coldfusion.monitor.event.MonitoringServletFilter.doFilter(MonitoringServletFilter.java:42)
    at coldfusion.bootstrap.BootstrapFilter.doFilter(BootstrapFilter.java:46)
    at jrun.servlet.FilterChain.doFilter(FilterChain.java:94)
    at jrun.servlet.FilterChain.service(FilterChain.java:101)
    at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:106)
    at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42)
    at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java:286)
    at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java:543)
    at jrun.servlet.jrpp.JRunProxyService.invokeRunnable(JRunProxyService.java:203)
    at jrunx.scheduler.ThreadPool$DownstreamMetrics.invokeRunnable(ThreadPool.java:320)
    at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:428)
    at jrunx.scheduler.ThreadPool$UpstreamMetrics.invokeRunnable(ThreadPool.java:266)
    at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)

[misterdai]

Hmmm... could you rerun the code with the cleanUp arguments wrapped in a JavaCast each, to make sure they are being passed as strings.

lc.sessionTracker.cleanUp(JavaCast('string', application.applicationName), JavaCast('string', lc.sessionId));

[JamesHookerMSO]

I believe I tried that - had the same thought - but with the same result unfortunately. Exactly the same stack trace. Very confusing..

[misterdai]

Okay... How about we take a look at what it 'thinks' is in the sessionTracker variable by doing a dump on it. Throw a screenshot of it in this issue.

[JamesHookerMSO]

Sure - here's the screen shot. As you can see, there's no cleanUp method defined - even with arguments different to what we're expecting. The first two dumps are the Application and Session scope.

[misterdai]

Okay, I'm really puzzled. Clutching at straws now but have you got J2EE Sessions enabled or any other session related settings that you think would cause this? If not, I'm starting to think Adobe may have started removing methods or protecting them somehow, to stop features being backported or people poking around.

[JamesHookerMSO]

I've not got J2EE Sessions enabled, and no other out of the ordinary session settings. I reckon you're right, the declaration of the cleanUp method must have been changed in one of the more recent 'hotfixes'. What a pain.

The implementation of SessionRotate that I was working on (which WAS kind of working) has kind of flopped now anyway, which is a shame, so the requirement for sessionInvalidate is a moot point..although, I just noticed in the above screen grab that a method named 'sessionInvalidate' is now exposed.

Could it be that they've changed the declaration of cleanUp, but implemented sessionInvalidate? If that's the case, if we could find out which subversion they changed the declaration of cleanUp in, we could test for that and use either the current method to implement sessionInvalidate, or use the pre-existing method sessionInvalidate (or you could just check for the existence of sessionInvalidate in the SessionScope in the first place, I guess..)?

Odd stuff - thanks for your time anyway :)

[misterdai]

It's a possibility, I'm going to run a few checks on that version of CF9 and earlier ones (9.0.1, then maybe hotfixes) to see if I can work out when it changed. Then do some testing to see if SessionInvalidate() does the job. I do seem to remember though, that SessionInvalidate does something like expire the session but not destroy it, so if a user hit the same session again before it is garbage collected, they get their old session back. Might be good enough though for session rotation, with the other steps it takes.

[JamesHookerMSO]

I've just checked against a colleages version of CF9 (9,0,1,274733), and the CleanUp method is publicly available, so yeah, it looks like they've changed the declaration somewhere between 274733 and 282541. Great!

[misterdai]

Just to confirm to anyone else who encounters this issue. Adobe appear to have taken ColdFusion 10 session handling code and used it in at least CF9.0.1 + CHF1. Unfortunately, they protected the .cleanUp(string, string) method and even using Java reflection to access it, it no longer works.

Need to find an alternative solution, otherwise CF9 support for this part of CFBackport is considered broken.

[ghost]

I'm not certain how relevant this may be, however I hope it points in a direction:

Perhaps using: getPageContext().getSession().invalidate() to invalidate the session. Subsequent request with that sessionID will get an error trying to access the Session scope but the memory will not be reclaimed until the actual session timeout.

What you can do is session.setMaxInactiveInterval(int) set it to very a low number in ms so it expires right away and release the memory. Then do a cflocation and for safe mesure use addToken="no"

[nikitul]

sessionInvalidate() will do the job. Now the point is how to verify if we will use sessionInvalidate() or cleanUp() I've tried with structKeyExists in metadata but no luck... Did you find a solution for this?

[nikitul]

I ended up using SERVER.ColdFusion.ProductVersion to determine which function to run