Losing sessions after moving to CF10

[tribule]

Hi,

We recently moved an application from CF 7 to CF 10 and have since noticed that browsing to a non secure page (http) to a https page makes the server lose our log-in session. Our site has a log-in page, and this is served securely. When the user logs in they can access all other pages that securely link from that log-in page. But, as soon as they click on a non-secure page, the session is lost.

This is a clean CF 10 install, not an upgrade. Are there any known issues with sessions and HTTPS in CF10 that we should be aware of? I printed out the session/cookie scopes on each page and it seems we get a new JSESSIONID for http/https sites, even though they have the same domain.

Our cfapplication tag is defined as:

cfapplication name="ourSite" clientmanagement="yes" sessionmanagement="yes" sessiontimeout="#CreateTimeSpan(0, 0, 20, 0)#" setclientcookies="yes" setdomaincookies="no" clientstorage="Cookie" scriptprotect="all"

Can anyone please shed some light on this? The domain is the same between http/https calls, so surely CF should be able to retrieve the cookie?

Thanks,

Mark

[tribule]

A quik finding. I took CFDUMP of the cookie scope and then copied the CFID and CFTOKEN in to URL parameters and passed them to secure pages, and they worked fine. Insecure pages still drop the session.

It seems ColdFusion 10 is not copying the CFID and CFTOKEN variables to the insecure pages. Anyone any ideas why, and how to resolve?

[David-Smith]

I wonder if that's a browser issue.  There have been several ocassions where I had session info dropping (not related to SSL), and I was SURE it was related to CF, but then as a last ditch effort I had the user completely reset their browser settings back to default, and voila, no more session problems.  Just an idea.  Btw, when this was occuring, some users did not have the problem, and others did, so there was clearly something specific to the client.  Maybe yours is different.  You might also use a debugger like Firebug for Firefox to see everything going on in the HTTP calls.  Chrome and IE have bebuggers already, just hit F12 to enable them, but personally I like Firebug.

[tribule]

David, I tried resetting the browser as you said, but to no avail. I also tried five other different browsers; all the same issue. Something has changed in CF10 and it seems to be to do with CFIDs and sessions. I know that the CF Admin no longer allows multiple logins using the same user id, but something else has changed in CF10 to do with session management. I tried a JVM parameter that returns sessions to their CF 9 mode, but that did not work either.

What I found out was that if I went to the login page securely, all subsequent secure pages retained the session, but insecure ones would not. So, I just made the login page use a http:// link in the form submission method, and that overcomes the issue since all subsequent pages are then http:// links. The solution seems to be make ALL pages served as either http:// or https://. Pages that are secure and post successively to other secure pages are fine, e.g. our e-commerce payment pages.

Very strange this, and no still no definitive workaround or response from Adobe. A cookie with the same domain should be served irrespective of the page being http:// or https://, indeed my own test pages show the same cookie is served in both cases.

[David-Smith]

Did you try looking at the HTTP calls using a debugger?  Sometimes you will see things not normally visible to the eye, such as a redirect or something else happening that you weren't aware of or expecting in the transfer stream.  Of course, there are a ton of variables involved in this scenario so who knows.  I don't do anything between secure and non-secure URLs so maybe I'm not the right person to help you troubleshoot.

[tribule]

FireBug et al do not seem to work in https:// mode as the pages are encrypted, so I cannot see anything Oh well, we have a workaround, but not sure if the issue is CF10 or our code.

[DCwebGuy]

That's weird.  I just tested Firebug and Chrome's built-in debugger while my public site is in SSL mode, and I can see everything in the debug console fine, just like if it was in non-SSL mode.  Yeah, I guess you may have other issues, or the issue is with the code itself.  It's going to be hard to troublshoot any further unless you can offer us a public link to test your site, or provide some code or something.

[tribule]

Dcwebguy, my bad. For some reason Firebug was not installed correctly in Firefox and I kept getting a blank screen. I used Firebug in Chrome instead and I can see the cookies as you correctly say. So, I checked again, and the CFID and CFTOKEN are the same between the https:// and http:// versions of the site. The JSESSIONID changes between them, however. Same issue though; the session is terminated when I navigate from a secure page to an insecure one. Perhaps it is our code then? Unfortunately I can't post the code nor identify the site unless I get permission.

It seems as if some code in our item is killing the session under CF10, whereas it did not in CF7. Going to be a hard one to locate since the code is legacy and volumous.

[DCwebGuy]

A couple of things:  First, when you enable the J2EE session variables, ColdFusion does not use the CFToken or CFID cookie value.  Second, from a security point of view, the JSESSIONID changing itself between secure/non-secure URL is the correct behavior, because a attacker could steal the session id/cookie used in https if the same session id/cookie is used in http too.  The simplest solution is to use one or the other URL, in other words, make everything secure or not secure.

[tribule]

I enabled J2EE sessions previously, and that yielded the same outcome - the session was lost between secure/insecure pages.

The problem with allowing https:// URLs throughout the site is that Google can penalise websites for duplicate content, and so it is SEO best practice not to allow both secure/insecure versions of the same pages (however in saying that, there may be a new way of using rel=canonical to avoid penalties by specifying only the insecure address on all pages of the site.)

We only want some pages to be secure, like the customer login and their order pages etc. That is all ok until the user clicks on a http:// link, and then their session is lost. We'd like the user to stay logged in and be able to browse both, and this used to work on CF7. Alas this behaviour no longer works (for us at least) on CF10. Finding the code that could be causing this is our task for another day I think.