losing jsessionID when making cfhttp call?

Question

For years, I've used <cfhttp url="http://myserver.com/myFile.cfm?#session.urlToken#"> to do screengrabs and use the currently-logged-in user's session scope. This has not been a problem under CF8/IIS6 environment. I've recently moved the application to a CF10/IIS7 environment and it does not like this call. The entire application is managed by cflogin, so it just returns my login screen. After doing some digging, I can tell that the jsessionID the cfhttp response header contains is not the same jsessionID I am sending via the url. Of course, this causes the server to think it's a new session and return the login screen.

I know setting this up with SSL is a pain and I've wrestled with it a lot in the past, but this setup is strictly http over port 80.

Things I've tried:

* uncheck "Use UUID for cftoken" in cf admin

* uncheck "Enable Global Script Protection"

* parsed the session.urlToken variable to send each variable (CFID, CFTOKEN, JSESSIONID) as a url/cookie via cfhttpparam

* turned off "HTTPOnly" for session cookies

I've even looked at the resulting #session.urltoken# variable and tried to hijack the session from another machine - no dice. It still just returns the login screen. On my CF8 box, I can hijack the session with this information.

Any clues as to things to try? My hunch is that it is a security thing and I thought for sure unchecking "Enable Global Script Protection" would solve it, but it did not. I know the jsessionid format is a little different with CF10 (CF9?) as it is "XXXXXXXX.cfusion". I thought the ".cfusion" might have been causing confusion somewhere in the setup - IIS thinking it was a file type and denying it via request filtering? But, that wasn't the case either.

Any help is greatly appreciated.

12Robots · Accepted Answer

Yes, I did notice that. I should have probably mentioned that at some point. That was initially breaking my myfile.cfm?#session.urlToken# solution because it didn't like the period in the url. Even wrapping it in #urlencodedFormat()# didn't help. However, I could send the variable via <cfhttpparam type="url" name="jsessionID" variable="#cookie.jsessionID#">. It didn't error out, it just didn't work.

God damn you Adobe forums. You just hosed up 15 minutes of typing.

Starting over:

After 10 minutes of researching this (so please take it with a grain of salt) I found something unique with CF10 and JEE tokens and that is the dot in the session token. This dot is getting encoded when you try to pass it as a cookie. I found that the following allowed me to persist the session.

Note that I also foudn that Tomcat (which is handling the JEE sessions) is case sensitive as well. So the JSESSIONID cookie you pass MUST be in uppercase letters.

I was NOT able to get the session to persist by passing the token on the URL. Regardless of encoding. This may be a bug in CF10. If it is the session fixation causing it, then using the JVM argument combined with using uppercase JSESSIONID should resolve that.

Hope this helps,

Jason

12Robots · Answer

When you say: "parsed the session.urlToken variable to send each variable (CFID, CFTOKEN, JSESSIONID) as a url/cookie via cfhttpparam"

Do you mean that you tried sending the values using <cfhttpparam type="cookie" name="JSESSIONID" value="#SESSION.jsessionid#" />?

jason

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded