Hi Charlie, Thanks for the informative post that's very very helpful. We are currently running CF 9.0.2 on our existing Production setup so Session Fixation is already in play and even passing the JSESSIONID around in some parts of the site when jumping from HTTP to HTTPS and back it appears to never have skipped a beat. Yet when moving to CF10 strange things have been happening with the session and when I inspect the headers when jumping between the domains CF is definitely issuing a different set of session cookies.
We never had the CFCOOKIE line in the onSessionStart() prior to this migration so that was more of a last ditch attempt to "help" the jsessionid cookie perist but to no avail. I wasn't aware of that new encodeValue attribute so I'm going to make a few changes now to A. Remove all instances of persisting the session through URL params, B. Implement the encodeValue setting for the cookie, and C. take a much closer look at the page headers to see if I can see something obvious. Can i just confirm though Charlie that it is expected behaviour for J2EE sessions in CF10 to persist across multiple subdomains using browser session cookies only? I've intentionally removed the timeout on that JSESSIONID cookie to have it persist only as long as the browser window is open and to satisfy our PCI Compliance requirements, as was the need to push the entire application to function over HTTPS. Thanks! Phil On Thursday, 3 April 2014 11:06:38 UTC+10, charlie arehart wrote: > > Yes, Phil. Many have had such issues. There are some subtleties to when > some experience it and not others. > > One thing I will suggest: use a client dev tool to watch closely the > cookies being sent and received between the browser and CF. Watch for > what’s changing, what’s duplicated, and ESPECIALLY whether the values you > set on the server (as in your CFCookie) are exactly you expect when > received in the response by the client. > > For instance, there’s a new encodeValue attribute for CFCookie (in CF10) > which can be used to change the default that has CF urlencoding any value > you may set, which could be a reason things do not work as you may expect > when setting cfcookie. (Of course, that would have no impact on the issue > you raise for folks who do not set cfcookie themselves, but many do, and > this is one of the ways that problems may start.) > > In fact, you may want to try not setting the jsessionid cookie at all. I > had a client doing that, and he stopped it, and his problem went away (I > proposed he might have resolved it with the new attribute above but he > realized he really didn’t need to be setting it at all.) > > Also, you mention setting the jsessionid on the query string. That’s > another thing that’s being handled differently since the session fixation > fix, I think you’ll find. You may want to avoid doing that, or again at > least pay close attention to the cookies that CF is trying to set. You may > find that it’s doing session rotation in the background on you, which > should work fine, but maybe your attempts to rewrite the cookies is being > confused by that change in behavior. (This notion of session fixation and > rotation is not new for CF10, but was added in a CF security hotfix in 2012 > for CF 8 and 9 which many simply never applied at the time, or only got > recently after updating their servers with the recent spate of > vulnerabilities, whether adding security hotfixes in 8 or 9.0 or 9.0.1, or > moving to 9.0.2 or 10 which automatically included any available as of May > 2012.) > > HTH. > > /charlie > > > > *From:* cfau...@googlegroups.com <javascript:> [mailto: > cfau...@googlegroups.com <javascript:>] *On Behalf Of *Phil Rasmussen > *Sent:* Wednesday, April 02, 2014 6:26 PM > *To:* cfau...@googlegroups.com <javascript:> > *Subject:* [cfaussie] CF10 Cross Domain sessions with HTTPS > > > > Hi Guys > > > > Just wondering if anyone has come across an issue in CF10 whereby sessions > are dropped when crossing between HTTP and HTTPS, even though the > JSESSIONID is being explicitly passed in these links which had worked for > us for over 5 years without fail prior to CF10. From what I have read there > appears to be a big change to address the Session Fixation security issues > which would explain the HTTP/HTTPS drops but I can't find a workaround for > this. > > > > Essentially we have CF10 installed with J2EE Session Management turned on, > and the default HTTPOnly set to true. In the application the domain > structure looks as follows: > > > > https://book.domain.com > > http://profile.domain.com > > http://approve.domain.com > > > > When crossing between the domains (which had worked for many years prior) > the session drops and CF issues a new set of session identifiers. In order > to try and bypass the SSL issue, i've switch the entire application over > the HTTPS so at no stage will the session or cookies be served over HTTP, > which works fine if the user doesn't cross domains, but the moment a > different subdomain is clicked (ie to make a booking) then the session > drops. > > > > Even setting a cookie in the onSessionStart() as follows has no effect: > > > > <cfcookie name="jsessionid" value="#session.sessionid#" domain=". > domain.com"> > > > > Has anyone come across this behaviour migrating to CF10? > > > > Cheers > > Phil > > -- > You received this message because you are subscribed to the Google Groups > "cfaussie" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to cfaussie+u...@googlegroups.com <javascript:>. > To post to this group, send email to cfau...@googlegroups.com<javascript:> > . > Visit this group at http://groups.google.com/group/cfaussie. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "cfaussie" group. To unsubscribe from this group and stop receiving emails from it, send an email to cfaussie+unsubscr...@googlegroups.com. To post to this group, send email to cfaussie@googlegroups.com. Visit this group at http://groups.google.com/group/cfaussie. For more options, visit https://groups.google.com/d/optout.
