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.